EEVDF Scheduler May Be Ready For Landing With Linux 6.6

[Mitch]

I wonder how they test its performance, the use cases are complex. For example it probably wont give a game more FPS but it might improve upon stutter/jitter or your GUI might be more responsive when the system is under load. Well, unless it changes how cache is hit or something like that.

At least in gaming, you have average FPS, low 1% FPS, and low 0.1% FPS. I imagine the latter two metrics would benefit (increase) from EEVDF. And it may even be something that improves, especially while other loads are running.

So three benches I think that may highlight EEVDF's benefits are benchmarking games that are highly CPU bound, each with
1. No other tasks on system
2. Background, low priority tasks on the system
3. Other, high-priority tasks on the system.

Not an expert in this area, but I'm guessing this isn't far from methods of demonstrating real improvement, since this new scheduler is theoretically the same throughput, but way better latency. And latency is something that's a bit trickier to see in conventional benchmarks. Another, less scientific method to test, might be to test system responsiveness under various workloads.

Michael also benched MUQSS and BFS in the last, and those used to be quite ambitious in latency and responsiveness guarantees vs CFS, which is what EEVDF looks like it may replace.

[waxhead]

Not that I honestly think that anyone here will notice any difference, but it will be interesting to see how the EEVDF scheduler handes the shortcommings of the CFS that was pointed out in "A decade of wasted cores" as well as the recent mentioning of the NEST scheduling algorithm. Or quite simply - how will EEVDF compare with CFS when being used on highly dynamic hardware where frequencies change and different cores have different performance properties.

[varikonniemi]

It looks a bit too good, at least the BORE version on openbenchmarking. Surely there must be some drawback for all that gained performance (not only latency, but raw performance!)

[smitty3268]

The original patchset had a comment from Meta saying it was bad for their workloads. Didn't ever see any reply to that, so I don't know if it got fixed or not.

[Paradox Ethereal]

Yeah, benchmarks that show actual framejitter and actual FPS drawn on screen. Not just theoretical benchmarks outside the whole loop of code.
It doesn´t matter if internal performance is high, if other bottlenecks bother it. Renicing X to avoid that being a bottleneck too would probably be part of it.
Last time I checked (many years ago) the kernel was nearly optimal with regards to OS-jitter. It just needed some hundred microseconds to get there, and it would be unnoticable.

Peace.

[Errinwright]

It looks a bit too good, at least the BORE version on openbenchmarking. Surely there must be some drawback for all that gained performance (not only latency, but raw performance!)

Got a link to this comparison?

Furthermore, how does this approach compare to the NESTED scheduler approach?