4 ms·

"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

"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 3y ago
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.
- wsc981 3y ago
  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 3y ago
    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.
- ta8645 3y ago
  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 3y ago
    A kernel compile is not CPU bound.
    - antiframe 3y ago
      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 3y ago
        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.
    - bheadmaster 3y ago
      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 3y ago
        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.
- tuetuopay 3y ago
  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.

westhanover 3y ago

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.

wsc981 3y ago
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 3y ago
  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.
ta8645 3y ago
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 3y ago
  A kernel compile is not CPU bound.
  - antiframe 3y ago
    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 3y ago
      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.
  - bheadmaster 3y ago
    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 3y ago
      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.
tuetuopay 3y ago
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.