[SOLVED] Desktop painfully slow on Linux 4.8

pumaking · 2016-11-09 21:38:52

Hello,

When running the new 4.8.2 Linux kernel (and 4.8.6 which I booted today), my window manager (IceWM) is really slow. Alt-tab has lag on the order of a second and opening new terminals is the same. Downgrading to Linux 4.7.6 however (with "pacman -U") and rebooting removes the issue.

What is the best way to investigate? Before downgrading the kernel, I tried downgrading the xf86-intel-video package with no success. My graphics card is Intel (on a laptop): "Intel Corporation HD Graphics 520 (rev 07)". This is the Lenovo Thinkpad T460.

I'll be happy to provide more info to narrow down the problem.

Thanks!

Last edited by pumaking (2016-11-17 18:15:44)

jasonwryan · 2016-11-09 21:44:43

htop

pumaking · 2016-11-09 22:00:26

htop doesn't really seem like the best way to debug this. The CPU is not pegged. In fact, the CPU usage looks higher with the correctly operating kernel (4.7.6).

For example, resizing an xterm window using the mouse is tremendously laggy using 4.8.2. htop doesn't show excessive usage during this and in fact the CPU% of Xorg is higher under Linux 4.7.6 than Linux 4.8.2 (approximately 25% vs 15%, but again, hard to see by eyeballing htop).

jasonwryan · 2016-11-09 22:08:20

Try removing the intel driver and using native modesetting. The wiki has the details.

pumaking · 2016-11-09 22:27:15

After removing the xf86-video-intel package and rebooting, the slowness is the same. Is there something explicit that needs to be done to enable native modesetting? Is there a reason why the driver would work with the older kernel but not the new one?

Trilby · 2016-11-09 22:39:33

pumaking wrote:

Is there something explicit that needs to be done to enable native modesetting?

Nope. If you removed the package and the lag is still there, the video driver is not the issue (though this was my suspion too).

pumaking wrote:

Is there a reason why the driver would work with the older kernel but not the new one?

Yes. A long history of the x11 intel video driver being buggy as hell and needing to be patched up with every new kernel. The known issues frequently lead to symptoms exactly like what you have described.

R00KIE · 2016-11-09 23:20:24

Why linux 4.8.2? The current version is 4.8.6, please do a full system update and check if you still have problems, then we can go from there.

eschwartz · 2016-11-10 01:16:14

R00KIE wrote:

Why linux 4.8.2? The current version is 4.8.6, please do a full system update and check if you still have problems, then we can go from there.

Because...

pumaking wrote:

and 4.8.6 which I booted today

...

I was having the same problem on linux-ck, but had not yet gotten around to trying the stock kernel. I guess I can skip that...

After starting Firefox, within minutes my entire system started grinding to a halt.

ngoonee · 2016-11-10 01:54:15

'Grinding to a halt'? What's RAM usage look like?

pumaking · 2016-11-10 02:09:52

Eschwartz wrote:

After starting Firefox, within minutes my entire system started grinding to a halt.

I'm not sure that is the same issue. Firefox and Chrome both still work quite well. The slowness is apparent immediately after boot and doesn't really get worse over time.

I made two videos that show the slowness but I'm not sure how to share them. The biggest impact is the ~1 second delay between when I press the keys to open a terminal and when the terminal box appears.

eschwartz · 2016-11-10 02:14:53

ngoonee wrote:

'Grinding to a halt'? What's RAM usage look like?

Before or after I reverted to 4.7.7?

That was one of the first things I checked, too. The RAM usage was completely normal, probably somewhere around 1.5 GB out of 2GB used.
It is not a RAM problem.

At first I thought it might be something to do with the -ck switch to MuQSS, so I downgraded and figured I would try again after it is more stable -- too lazy to compare to the stock kernel when I had a guess at what might be the problem, and a reasonable stopgap measure. (This does seem like the kind of thing that could be caused by flawed CPU scheduler logic.)
But if this is the same problem, then that can't be it...

When I find the time, I guess I will try the stock kernel and see how things go.

R00KIE · 2016-11-10 13:38:19

If changing _only_ the kernel fixes the issue then it's "easy" to find the problem, bisect the kernel and find the offending commit. You can then report the bug upstream and mark it as a regression, say which commit broke things and I'm sure that very soon someone will be taking a look at it and provide a fix or patches for you to test.

pumaking · 2016-11-12 03:18:15

R00KIE wrote:

If changing _only_ the kernel fixes the issue then it's "easy" to find the problem, bisect the kernel and find the offending commit. You can then report the bug upstream and mark it as a regression, say which commit broke things and I'm sure that very soon someone will be taking a look at it and provide a fix or patches for you to test.

Ok I did the bisection and the slowness is not present on 194dc870a589 and IS present on 554828ee. This is the diff: https://git.kernel.org/cgit/linux/kerne … 8af9fd9d65

Something about hashing. Is this even possible or did I screw up somewhere? I check out 554828ee, build, install, reboot, desktop is slow. Checkout the other, repeat, and slowness is gone. Does this point to a bug in the driver that is exposed by a different random ordering perhaps?

R00KIE · 2016-11-12 14:18:51

You have bisected and that is the result, it is what it is. That commit may not be the the actual culprit and only uncovers a problem somewhere else but it is the best evidence you have, now it's time for you to open a bug report upstream and let the kernel developers take a look.

You have detected what seems to be a regression in the kernel and you have done your homework to find out what made it regress. From my limited experience, regressions are dealt with quickly, but you may be asked to try a few patches or try a few more things to determine for sure that is the problem commit.

Don't forget to provide as much useful information as possible in the bug report.

hughitt1 · 2016-11-15 14:20:58

I can confirm the issue for ASUS ZENBOOK UX31A (also Intel shared video/memory). Before loading X, things are not terribly slow, but at soon as Awesome is loaded, latency shoots up and the system becomes completely unusable (~5s delay for simple things like keyboard input).

To be sure, I tried booting into Windows and things are running smoothly (or as smooth as they could be) there, so it's not a hardware issue.

pumaking · 2016-11-17 18:14:52

This turned out to be a window manager issue. Instead of the CPU, icewm was now probing the temp of the wifi card and that slowed things down.

Arch Linux

#1 2016-11-09 21:38:52

[SOLVED] Desktop painfully slow on Linux 4.8

#2 2016-11-09 21:44:43

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#3 2016-11-09 22:00:26

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#4 2016-11-09 22:08:20

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#5 2016-11-09 22:27:15

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#6 2016-11-09 22:39:33

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#7 2016-11-09 23:20:24

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#8 2016-11-10 01:16:14

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#9 2016-11-10 01:54:15

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#10 2016-11-10 02:09:52

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#11 2016-11-10 02:14:53

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#12 2016-11-10 13:38:19

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#13 2016-11-12 03:18:15

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#14 2016-11-12 14:18:51

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#15 2016-11-15 14:20:58

Re: [SOLVED] Desktop painfully slow on Linux 4.8

#16 2016-11-17 18:14:52

Re: [SOLVED] Desktop painfully slow on Linux 4.8

Board footer