Stop Being a Linux Kernel Code Parrot: Embrace Reality‑First Understanding

I have been a programmer for more than 20 years and have observed that many peers approach learning the Linux kernel incorrectly; they merely repeat kernel code instead of truly exploring it.

We have repeatedly emphasized that code is a reflection of reality. When studying Linux kernel code, the first step must always be from reality to code (not the reverse), followed by continual back‑and‑forth comparison between reality and code, with the initial focus on understanding the real‑world problem.

Consider a system with n CPUs and

m

task_struct

instances to run. Any operating‑system scheduler inevitably faces the following questions:

How many task_struct objects need to run, and how should they be recorded and organized in a data structure?

These task_struct objects have differing characteristics—some are periodic, some are urgent (e.g., a person with diarrhea needs higher priority than a normal bathroom request), some emphasize fair quotas, others are indifferent. How should these differences be represented?

Assuming we have already maintained the task_struct collection (question 1), we must decide the scheduling strategy for the diverse task_struct instances—specifically, which should run first.

Given that task_struct instances have varying urgency, can a less urgent task running on a CPU be pre‑empted by a more urgent one? If so, which tasks can pre‑empt which, and under what conditions?

How should the

m

task_struct

objects be placed on the n CPUs? Which tasks fit which CPUs? Could an imbalance cause some CPUs to be overloaded while others are idle? How does the CPU topology (proximity of CPUs) affect placement based on task relationships?

Must the arrangement of all task_struct objects be flat? For example, if user A launches 100 kernel‑compilation threads and user B launches 20, could A’s threads monopolize 80 % of CPU capacity while B gets only 20 %? If such imbalance occurs, should we adopt hierarchical management—grouping tasks by user, ensuring fairness between groups first, then within each group?

Is there a universal scheduler that is simultaneously friendly to every scenario? If not, how should a scheduler adapt to varying business‑scenario requirements?

These questions constitute our “celestial inquiry.” If you were one of the authors of the Linux kernel scheduler, how would you respond? We never passively accept how others solve these problems; we aim to be pioneers, not mere repeaters of Linux kernel code.