Announcement

Collapse
No announcement yet.

Linux 5.11 Is Regressing Hard For AMD Performance With Schedutil

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • onlyLinuxLuvUBack
    replied
    Maybe next time you could also compare how the latest clear os kernel is doing and the latest oracle uek kernel is doing in these graphs so we could see how far away 5.11/5.12 are ? are we in a sand pit or are we on the green?

    Leave a comment:


  • aufkrawall
    replied
    Originally posted by ssokolow View Post
    That's why it's important to test them. To make sure bad defaults get called out.
    Reality is kernel developers don't care. intel_pstate=powersave has been such a gigantic mess for years, it's hopeless. Similar things seem to apply to schedutil, after many years of work it's still far worse than Windows balanced power plan.

    Leave a comment:


  • mulenmar
    replied
    Grinch, just because Michael mentioned a Grinch stealing Christmas doesn't mean that you need to get huffy and defend against the entire article.

    We all know what in-development means.

    This wouldn't be the first time Michael's tests have prevented an otherwise unnoticed regression from making it to release.

    Chill.

    Leave a comment:


  • Grinch
    replied
    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.

    Leave a comment:


  • gregzeng
    replied
    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.

    Leave a comment:


  • hoohoo
    replied
    Soooo.....

    What scheduler does Clear Linux use ?

    Leave a comment:


  • Paul Frederick
    replied
    [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.

    Leave a comment:


  • sandy8925
    replied
    Originally posted by brent View Post

    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".

    Leave a comment:


  • ms178
    replied
    Originally posted by zoomblab View Post
    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.

    Leave a comment:


  • brent
    replied
    Originally posted by sandy8925 View Post

    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.

    Leave a comment:

Working...
X