Stop Being a Linux Kernel Code Parrot: Think Like a Scheduler Designer

The author, a veteran programmer with more than 20 years of experience, observes that many learners approach the Linux kernel by merely reproducing its code, missing the deeper exploration of the underlying system.

He emphasizes that studying the kernel should start by mapping real-world behavior to code, then repeatedly comparing reality and implementation to truly grasp the concepts.

How many task_struct instances need to be managed, and what data structures can record and organize them?

Given diverse task characteristics—periodic, urgent (e.g., a person with diarrhea needing immediate service), fairness‑oriented, or indifferent—how should these differences be represented?

Assuming a data structure for task_struct exists, how can the scheduler decide which task runs first among tasks with varying policies?

When a task_struct runs on a CPU, can more urgent tasks preempt it, and under what conditions is preemption allowed?

How should m tasks be distributed across n CPUs, considering task‑CPU affinity, CPU topology, and load balance (avoiding both overloaded and idle CPUs)?

Is a flat arrangement of all task_struct instances always appropriate, or should hierarchical management be used to ensure fairness between groups of tasks (e.g., many threads from one user versus fewer from another)?

Does a universally optimal scheduler exist for all scenarios, and if not, how should a scheduler adapt to varying workload requirements?

These questions serve as a self‑challenge for anyone involved in Linux kernel scheduler development, urging them to be innovators rather than passive repeaters of existing code.