[bluejekyll]

"I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." — Andrea Righi

I think that pretty clearly summarizes the entire reason for doing this and the excitement that it works and works well.

[westhanover]

I don’t understand why he measured the performance gain like he did. Playing a game with a background kernel compile running is a very unique gaming benchmark.

[tuetuopay]

I think it's more because a game is very sensitive to jitter in CPU performance, and can reflect pretty well the responsiveness of the machine with a heavy load in the background. You can replace the game with scrolling a webpage, using slack during compile times, etc. With a game, you get a hard number (FPS) and a very visual indication of how well the load is doing (e.g. stuttering is very noticeable and is a pretty good indicator). So the game is not the point, it's IMHO a visualization of the effectiveness of the scheduler.

[ta8645]

It's akin to running any CPU intensive task while playing a game... The hope would be to make the most progress possible without stalling the foreground process.

[jacquesm]

A kernel compile is not CPU bound.

[bheadmaster]

That highly depends on your system configuration.

That being said, my personal experience is that compiling large C projects on my machine with a fast SSD usually uses all cores on almost 100%, which would make it CPU-bound.

[jacquesm]

Yes, true, you can construct a machine on which any project you care to run is CPU bound. But meanwhile on my pretty beefy servers compiling a kernel from scratch is very much i/o bound. Maybe if I run it twice in a row after all of the caches have been prepped I can get it to be CPU bound but that's cheating, no? With enough RAM almost anything is CPU bound but that's not the normal situation. A typical laptop has 4 or 8 G of RAM and will rapidly consume all that while doing a kernel compile to the point that it's talking to the disk to a degree that it will slow down to where the CPU's are stalled.

[bheadmaster]

> Yes, true, you can construct a machine on which any project you care to run is CPU bound.

You can also construct a machine on which any project you care to run is I/O bound. Which kind of makes your comment "kernel compile is not CPU bound" kind of pointless, no?

That being said, I just downloaded kernel source on my old laptop just to do a sanity check, and it's pinning all 4 of my cores to 100%, so I don't know that to tell you. Perhaps your beefy server (with, I assume, a powerful CPU) is not a typical scenario.

[manifault]

Sorry? This is completely false. It is highly CPU bound. Especially front-end CPU pipeline bound.

[jacquesm]

You mean: I've picked my system components in such a way that kernel compiles are not i/o bound. But on an average machine a kernel recompile is very much i/o bound. To the point that people will go out of their way to get large amounts of RAM and very high performance i/o subsystems into their machines. But your average i7/8G run-of-the-mill machine is going to run into the i/o bottleneck pdq. On a 32 or 64G (or even more) RAM box with an NVME drive you probably can get it to be CPU bound. On my 16G laptop with SATA SSD it very much is, the CPU is only utilized about 60% or so.

[bheadmaster]

> You mean: I've picked my system components in such a way that kernel compiles are not i/o bound.

Then in your original comment, you also mean "I've picked my system components in such a way that kernel compiles are not CPU bound".

[antiframe]

That's an interesting claim. Do you mean on all hardware it's IO bound? I would think it depends on the disks, concurrency setting for make, memory size, memory speed, and number of availabile cores.

[soulbadguy]

Yes, all of those are important factor. And playing around with those factors (memory, IO speed etc...etc...) it;s easy to construct a system where CPU could be the limiting factor.

But it's still possible to make a claim that in general, most "in the real world" builds are limited by ram size (especially linking), memory bandwidth not really by CPU. The main reason is really that compilation is not as parallel as one might think.

Compilation used to be much more IO bound in the past. But these days with nvme drives and really aggressive OS file caching (and or ramdisk) IO is less of an issue.

Also note that this changes significantly moving from O2 to O3 where CPU (single thread) performance become more and more important.Same for partial recompilation.

[wsc981]

You have to do something while compiling a Linux kernel, might as well play a game as (I imagine) it can take a while :)

[rkangel]

Depends what you're compiling. A kernel for embedded (and therefore a trimmed down set of modules) on a decent machine can easily just be a minute or two. The kernel build system is pretty good at incremental compilation as well.