Browsers unbearably slow after update

Help
21

The 5.8 kernel has had a lot of eyes on it throught it’s RC period, a straight-up perf regression would have been found pretty quickly. My hunch is that this is still a userland issue (incl. Mesa), but that it is only pathologically bad when run on a 5.8 kernel.

@jlode switching back to 5.7 will get you a usable system, but eventually 5.9/5.10 will be the new default kernel and the performance issue could come back. If you still have the patience, bisecting nixpkgs is still valuable to track down this bug. I suspect you will need to also cherry-pick eb919fa to fix the qtquickcontrols build failure.

@xfix you are of course correct too. Something changed between v5.7 and v5.8 that causes a performance issue in the userland. It would be good to track it down too, and maybe it will help in identifying what userland-kernel interaction has regressed, but the kernel can’t take all the blame here.

1 Like
22

The 5.8 kernel has had a lot of eyes on it throught it’s RC period, a straight-up perf regression would have been found pretty quickly.

Unless it is yet aother cross-process timing attack mitigation, which indeed would hit browsers especially hard as they split all the things into processes.

If you still have the patience, bisecting nixpkgs is still valuable to track down this bug.

But then I am afraid one needs to start with finding a version which does not have this problem on 5.8/5.9, right?

23

I have the same hunch. The way most people write software, it’s very common that software only works properly on the system(s) it was written on, and only works by accident on some others.

Also, a version that works properly on 5.8 might not exist, right?

2 Likes
24

I have the same hunch. The way most people write software, it’s very common that software only works properly on the system(s) it was written on, and only works by accident on some others.

Note that the kernel is actually pretty strict about regressions, but in this case we have fraudulet-advertising-level corner-cutting on the side of a major hardware manufacturer…

Also, a version that works properly on 5.8 might not exist, right?

That’s the point

25

That’s why osx and mac hardware ‘seem’ to be more stable, and has less integration problems, they have support a smaller subset of hardware, wireless drivers, graphics chip or a least (in the past) a certain level of hardware quality… You can actually regression test almost every hardware configuration you even sold. They all have access to schematics, and details documentation on the hardware works… the more you hide, the more linux people have to literally waste thousands of hours reverse engineering things…

You could never do that with linux, you’d have to keep every piece of hardware ever made… :-(.

If you support every piece of broken, cheap, copied, flimsy piece of hardware that ever existed, to be shipped to you where the maker gets their profit on the over charging you on postage…

You’ll find ugly hacks in the kernel source code, doing things to be make very broken pieces of hardware play nice.

and it’s not like all this broken hardware code is running in kernel space is it (well it actually… pardon my sarcasm , i know it’s a lower form of wit).

older kernels, there’s just a lot less going on, less complexity…

my personal thing is if your doing anything serious, don’t run experimental/cutting/bleeding edge kernels…but for fun… why not…

sometime it better the devil you know… than the devil you don’t.

hardware needs to be well tested, have open documentation, no mystery firmware binary blobs, and if the do have hardware quirks then the need to be workaround…

a utopia that will never happen,

you know all this already, but maybe some lost soul will come across this post years in the future and say ‘nothings changed’. ;-).

may i draw your attention to when a certain developer just had it with this hardware cat and mouse chase…

2 Likes
26

I may have misunderstood the problem. I was operating under the assumption that pkgs.linuxPackages_latest was v5.8 across the whole bisect range and that you had at one point a working (good) system on a 5.8 kernel. Under this assumption, bisecting nixpkgs is still valuable to find a user-space change that triggers pathological behaviour on 5.8.

If linuxPackages_latest is also changing across that range of versions, bisecting nixpkgs may be valuable to track down the kernel version change that causes the slowdown, if only to narrow the range of linux kernel commits you have to bisect.

27

I tried bisecting the kernel, but lots of 5.8 kernels cause boot problems (maybe just X11, I didn’t spend any time trying to debug it), and some don’t compile, so I think I should just stop here.

I’ll probably just stick with linux v5.4 until I get a new computer. Thanks again for all the help. :slightly_smiling_face:

@twoolie: No, my system was never “good” on v5.8.

28

I noticed the same issue (firefox especially sluggish but the rest of the system too), running 5.8 too. as I 've just added RAM (I was not sure whether that was responsible) I was not sure. Will try on an older kernel.

29

For the record, I now think the entire system is affected, not just browsers, so the title is misleading. I noticed that compiling Linux also takes >3 times as long on a “bad” system. The difference isn’t subtle, to say the least.

30

I confirm it’s the whole system. Even launching a terminal (in i3) was painful. I used an older kernel and the system was back snappy as it should. I had a look at dmesg and 1st there seemed to be an issue with my nvidia card, an outdated microcontroller (but for TSC_DEADLINE so it shouldn’t be the issue).

31

Aaaaand I found the problem. I thought I’d try googling the issue one last time with the new information (“linux 5.8 slow cpu”). Currently, 3 of the top 4 results are talking about the fact that intel_pstate defaults to “passive” on 5.8. The fix for me was to add:

    boot.kernelParams = [ "intel_pstate=active" ];

That’s somewhat infuriating, but what can you do…

17 Likes
32

sigh… like most software development these days, default configuration ‘options’ are not bugs, they are configuration options. or ‘bugurations’ as we say…

Does the nixos CI test performance via benchmarking of builds? Is this data available? Might be nice to see changes in performance vs package set vs kernel vs configuration (bugurations) over a period of commits.

33

I just updated NixOS to 21.05 and my CPU was getting pinned from Firefox trying to open simple webpages. I’ve never seen Firefox so slow. Added the kernelParam and it was a night and day difference. Thank you so much!

2 Likes
34

kernel space vs user space…never the twain shall meet

35

Reaaally should be the default, this issue was causing me a headache. Thanks!!