Linux 5.11 Is Regressing Hard For AMD Performance With Schedutil

[Guest]

Will someone please make a gofundme account so that we can fund AMD's Linux kernel support!!!

It's 2020 people, wtf?! :-|

Lol, AMD is a billion dollar company, they have plenty of money. They just don't give a crap about Linux support on consumer hardware (sometimes not even on the server side).

But of you want to fund someone, I'd be happy to work on fixing problems in AMD CPU and GPU drivers as long as I'm paid well enough for it.

[Guest]

Maybe the current schedutil implementation should be scrapped at this point. It's definitely a good idea to have some integration between process scheduling and cpu performance scaling, but benchmarks have shown again and again and again that the current implementation simply doesn't work.

This really is a good example of sunken cost fallacy.

Or it shouldn't be made the default, and they can continue tweaking it until it improves. No reason to throw away code unless it's entirely unsalvageable.
l

[Guest]

Good thing I saw the earlier benchmarks of schedutil, and switched to ondemand by default instead.

[brent]

Or it shouldn't be made the default, and they can continue tweaking it until it improves. No reason to throw away code unless it's entirely unsalvageable.
l

I think that ship has sailed. schedutil has been in the "tweak it until it can be shipped" phase for the last 2-3 years, without much success. And it has held up development of alternatives. Leading kernel devs still want schedutil to "eventually" replace all other cpufreq implementations and try to refuse to merge and discourage to develop new cpufreq implementations.

[ms178]

It seems that kernel development suffers in QA department (if there is any). Performance and reliability can be ruined at any time. Such problems can happen not only from unintended bugs but also from designed "improvements" which can have detrimental effects if they are not proven before commit with actual data and benchmarks.

Hardware companies should be doing the work Michael is doing.

BTW Michael, I remember you had found a nasty kernel regression on the transition from 4 to 5 and I didn't notice a follow-up on that.

I agree with you 100%, but I just want to point out that there are some efforts now in this area with the LKP project (done by Intel, see: https://01.org/lkp). You can spot automated messages from them on the LKML every so often with a message about notable improvements or regressions. But this scheduler regression is a great example that testing on several generations of Intel hardware is not enough to spot every regression. But that would be either the job of the patch author or AMD to fix.

[Guest]

I think that ship has sailed. schedutil has been in the "tweak it until it can be shipped" phase for the last 2-3 years, without much success. And it has held up development of alternatives. Leading kernel devs still want schedutil to "eventually" replace all other cpufreq implementations and try to refuse to merge and discourage to develop new cpufreq implementations.

True. Alternative cpufreq implementations shouldn't be discouraged. It would be like saying "we have ext4, no need to develop any more filesystems".

[Paul Frederick]

[QUOTE=Anarchy;n1228573]Will someone please make a gofundme account so that we can fund AMD's Linux kernel support!!!

/QUOTE]
How about an Intel® gofundme? Intel® has their own Linux distribution so they deserve our support. Their distribution could use a lot of work too. But at least they've started it.

[hoohoo]

Soooo.....

What scheduler does Clear Linux use ?

[gregzeng]

Nice to notice that performance per watt is now included. Users concerned about excess heating should be aware that most computers, including notebook computers, have inbuilt mechanisms to take overheating. Battery life maybe default, so Ubuntu has had is own high performance Linux Kernels, unlike other Linux distributions. These can be used in all Ubuntu based systems, & some Debian-based systems.

Ubuntu's high performance kernels available, are called "Low Latency". These are offered as ready to run compiled DEB failures as also for the beta releases, the Release Candidates, when published as source code, seconds after being released by The Linux Foundation.
Benchmark tests seem not available yet on these performance kernels.
Linux 5.11 is not officially released yet. When it is, benchmarks which compared it with other systems, should also include the performance version of the kernel.

[Grinch]

A lot of people seem to lack understanding of what development entails. Regressions are common when working on complex code, the Linux kernel is extremely complex. This is a in-development kernel, regressions are bound to happen, be found (if Michael was the first to spot this, very impressive, but something tells me the subsystem maintainers were aware of this) and fixed.

If this regression would make it to actual release, then YES, flames are indeed warranted, as of now it's just one of thousands upon thousands of regressions throughout kernel development.