"Nest" Is An Interesting New Take On Linux Kernel Scheduling For Better CPU Performance

[cj.wijtmans]

If we can set a desire latency per thread this would be nice

[ms178]

Patches are here: https://gitlab.inria.fr/nest-public/...image_creation

Lets see if this works on something newer than kernel 5.9

There is a newer version available in another directory: https://gitlab.inria.fr/nest-public/...ee/main/extras

But it is still 5.15 - CachyOS devs tried to port it to 6.0 but did not get it to compile due to the move from gnu89 to gnu11 which need to be addressed.

[Linuxxx]

It should be noted that they are comparing this to plain schedutil, which is an easy opponent to beat, because it's the second worst Linux governor in existence, only in front of powersave.

Only if this new scheduler can consistenly fair better than plain CFS + the performance governor would it be a real improvement, which they of course didn't benchmark.

(I wonder why...)

[onlyLinuxLuvUBack]

I hoper we can get a phoronix dance battle benchmark of BORE vs NEST vs CFS vs etc scheduler running some tasks like the 7zip and python3 threaded

[ryao]

I suspect that games will benefit from this.

[ms178]

FireBurn Good news, the ChachyOS devs got NEST to work with 5.19 and 6.0 (just a port - no guarantees!) and posted some benchmarks in their Discord, here is a link for 5.19: https://github.com/CachyOS/kernel-pa...001-NEST.patch

!!!!! WARNING: It seems that the ported NEST patch doesn't work with Intel CPUs or certain Kernel config settings resulting in a non-bootable system. !!!

Maybe even Michael wants to do some benchmarking with it? The readme says that it works with schedutil only, but you could try other governors as well. Happy experimenting everyone!

[sinepgib]

Thanks for your insight. I don't know much about these internals, hence I am shocked to get to know that such information is not already accounted for in today's schedulers as boost frequency behavior has a huge impact on performance. Also the scheduler needs to know about power management and core/cache layout, too. I guess that means that there are some performance gains still to be had in the future.

I think most schedulers are optimized for very busy cores, at which point there's not that much of a difference between cores (cache invalidation is more important for this case, but that's about keeping a given task always in the same core).
There's also a point to be made about market: on desktops and servers asymmetric cores are a new-ish thing, and that's probably where the impact of this will be greater. It's common in embedded, but embedded is the least mainline friendly environment.
And since some of this issues can be solved by the user (you can pin your thread to a core if you need to), it was probably less of a priority for the likes of Intel.

[JEBjames]

Michael

Typo "current;y-busy" should probably be "currently-busy.

[JEBjames]

Michael

Also grammar

"Nest was also worked on in cooperation with oracle Labs and University of Sydney."

"Nest was also worked on in cooperation with Oracle Labs and the University of Sydney."

[TeoLinuX]

I hoper we can get a phoronix dance battle benchmark of BORE vs NEST vs CFS vs etc scheduler running some tasks like the 7zip and python3 threaded

I fear that for high loads (Phoronix benchmarks try to max out the processors) the difference will be negligible.
If I understood well, this scheduler works its best on average loads. But maybe I got it wrong

I mean, what is a good metric to analyse? I think on a average load the real comparison analisys would be power efficiency: you use fewer cores at higher freq for less time. I think this has been used on iPhones for a long time, grouping tasks together in order to make the CPU work in "flames" of activity