Article does seem quite interesting at a first glance, but I can't say I'm a fan of these GenAI headers at all.
In his About Me
> But now, thanks to AI, I can speed up the process significantly. AI helps me research faster, draft clearer explanations, and refine my writing—allowing me to finally share this knowledge the way I’ve always envisioned.
So I think he's writting articles himself and then running them through LLM to proofread and fix style, and so on.
It is most certainly written with AI. Where are the references?
The only thing you really need to rely on at this point is, if someone who has actually contributed to the Linux kernel scheduler can verify all of this.
I'm not just triggered by the wording, I generally just find it hard to read. That familiar feeling of having read multiple paragraphs where nothing of substance was said, and you realize the text was either heavily edited or generated.
I'd love to read an article about the topic, but can't recommend this one if you expect high informational quality.
I wish the author explored CFS first, because not only is it simpler to understand, it's also the scheduler that the kernel ran for decades before switching to EEVDF.
Exploring CFS would also naturally lead to exploring its limitations (like why its bad for desktop interactivity), and so EEVDF can be organically introduced into the picture and we'd understand and appreciate it better.
This text repeats things that I have read many times before, maybe
because it's heavily AI assisted as other have suspected. But it fails
to answer my questions I have had unanswered for years.
Q1: Let's start with a single core machine. The explanations always say:
The scheduler does this and does that. As if the the scheduler would
be some external entity. In the single core machine there is only one
actor. The core that executes instructions. One after another. Where
the next one is either determined by the program counter or an
interrupt. I would really like a text that never changes
perspective. It's the CPU that does things (sometimes it executes code
belonging to the scheduler). It's never the scheduler that sits there
in an outside supervising position and can do things.
So lets take this pure user space while(1) task. The CPU jumps into
the timer interrupt code. The article says a flag will be set, but the
real preemption will happen later at a safe spot. So what code is
executed after the flag has been set? Where and how will it notice
that now we are at a safe spot to preempt?
Q2: The multi-core case. All texts write about "the scheduler". As if
we had n cores and 1 scheduler that supervises what they are
doing. But that's certainly not what is happening. I guess all cores
execute some scheduler code regularly (except the tickless ones, but
that's yet another story and rare on a "typical" machine). But how
does that work without creating a mess in the data structures? Well,
some synchronization primitives are probably needed. But how does that
scale for dozens and 100s of cores? I guess most structures are local
to a core and the global ones are modified rarely?
6 comments
[ 0.32 ms ] story [ 27.5 ms ] threadIn his About Me
> But now, thanks to AI, I can speed up the process significantly. AI helps me research faster, draft clearer explanations, and refine my writing—allowing me to finally share this knowledge the way I’ve always envisioned.
So I think he's writting articles himself and then running them through LLM to proofread and fix style, and so on.
The only thing you really need to rely on at this point is, if someone who has actually contributed to the Linux kernel scheduler can verify all of this.
If not, then you can't trust that text.
I'd love to read an article about the topic, but can't recommend this one if you expect high informational quality.
Exploring CFS would also naturally lead to exploring its limitations (like why its bad for desktop interactivity), and so EEVDF can be organically introduced into the picture and we'd understand and appreciate it better.
Q1: Let's start with a single core machine. The explanations always say: The scheduler does this and does that. As if the the scheduler would be some external entity. In the single core machine there is only one actor. The core that executes instructions. One after another. Where the next one is either determined by the program counter or an interrupt. I would really like a text that never changes perspective. It's the CPU that does things (sometimes it executes code belonging to the scheduler). It's never the scheduler that sits there in an outside supervising position and can do things.
So lets take this pure user space while(1) task. The CPU jumps into the timer interrupt code. The article says a flag will be set, but the real preemption will happen later at a safe spot. So what code is executed after the flag has been set? Where and how will it notice that now we are at a safe spot to preempt?
Q2: The multi-core case. All texts write about "the scheduler". As if we had n cores and 1 scheduler that supervises what they are doing. But that's certainly not what is happening. I guess all cores execute some scheduler code regularly (except the tickless ones, but that's yet another story and rare on a "typical" machine). But how does that work without creating a mess in the data structures? Well, some synchronization primitives are probably needed. But how does that scale for dozens and 100s of cores? I guess most structures are local to a core and the global ones are modified rarely?
Where are these 2 questions answered?