System slow after resume

Raam · 2017-06-11 09:42:05

Hi.

After resuming from a suspend-to-ram, google chrome freezes while tabs are loading. It becomes very slow. Same thing applies to firefox and chromium and I noticed a slowdown on Higan. I conclude that the entire system slows down but I can't be sure the issue isn't about graphics. I wound't know about hibernation at the moment.

I did my research and found this post, but it didn't help me. My laptop is Acer E5 575G, 12GB RAM, i5 7200U, NVIDIA GeForce 940MX. I use the suspend button on xfce, but the issue doesn't happen always . It usually happens when resuming after a long time (the whole night for instance).

I also noticed something I can't understand. The output of cpupower frequency-info before suspending is

  analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 3.10 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 3.10 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: 3.10 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes

If I suspend only once and the issue presents itself, the output does not change. If the problem doesn't happen and the system remains usable, the output changes one line like this:

....
  current CPU frequency: 519 MHz (asserted by call to hardware)
.....

Where the value will vary continously around that value.

seth · 2017-06-11 14:40:55

Since the cpu goes faster when the system becomes slower, sth. will keep it under load?
Did you check for offenders?
Does restarting the browsers change anything? (Ideally close before S3 and restart after resume)
Or a re-login (ie. X11 restart)?

Raam · 2017-06-11 16:04:36

Hi seth, thanks for the reply but I can't understand your first two lines: are you asking if there is a process with 100% cpu? No, there isn't.
Restarting the browser does not change anything. Restarting X (with systemctl restart lightdm) doesn't doesn't do the trick. Even if it did, I wouldn't be happy anyway.

seth · 2017-06-11 16:21:25

Not necessarily 100% but "much" - be sure to rely on "top" and not some fancy desktop indicator here.
Also, before becoming happy, you've to figure the cause here (and such exclusion tests should help on this)

Do you use any userspace frequency scaling tools? (things mentioned on wiki link below)
Does messing around w/ the governor settings clear the stage?
https://wiki.archlinux.org/index.php/CP … cy_scaling

Also try to disable speedstepping in BIOS/UEFI itr. to see whether it makes any difference.

Finally: ensure this is actually about the cpu and the *current* frequency isn't just a red herring - compare

time echo "scale=5000; a(1)*4" | bc -l

on a good and bad system (this is gonna take some seoncds and then spits out a pretty accurate version of π ;-)

Raam · 2017-06-11 22:48:53

I installed cpupower and i7z, but I didn't use them, except cpupower to check the frequency and once I tried to set the governor to "performance" on a bad system, without results. Then I put it back to "powersave".

I have never noticed options about the cpu in the BIOS but I will check next time.

I did a reboot and ran cpupower frequency-info giving out current CPU frequency: 3.10 GHz. I also executed your script:

	real	0m19.956s
	user	0m19.932s
	sys	0m0.004s

	real	0m20.023s
	user	0m20.023s
	sys	0m0.000s
	
	#timing is also consistent with a working system after resume (I mean when "current CPU frequency" is ~500MHz)

	#open chrome. close chrome. System works (obviously).

	real	0m19.145s
	user	0m19.142s
	sys	0m0.003s

	real	0m19.618s
	user	0m19.619s
	sys	0m0.000s

Then I suspended for a few seconds, thinking I would get a good system, because usually I can't trigger the problem with a quick sleep. But I ran again cpupower frequency-info and it gave out current CPU frequency: 3.10 GHz. I already knew the system was bad, because I would have expected ~500MHz.

	real	0m21.808s
	user	0m21.806s
	sys	0m0.003s
	
	real	0m19.149s
	user	0m19.146s
	sys	0m0.003s
	
	#open chrome. close chrome. [sound works]
	#open higan. close higan. [graphics and sound lag (maybe because the audio is synced with the graphics, so it doesn't matter)]
	#the issue is present.
	
	real	0m21.791s
	user	0m21.791s
	sys	0m0.000s
	
	real	0m19.119s
	user	0m19.115s
	sys	0m0.004s

I ran htop. Nothing really interesting. The highest was usually /usr/lib/xorg-server/Xorg with ~3%

It bugs me the ~500MHz when the system works after suspend. I don't understand it. Nonetheless I think it's not really a cpu problem, but it may be a gpu problem or something else, I don't know.

Last edited by Raam (2017-06-11 22:50:14)

seth · 2017-06-12 05:55:18

It's at least not a single core performance issue.

Memory load?
Network problem (would be obvious candidate for for browsers, no idea about higan; try to restart the network)
General I/O issue? (iotop)

And of course check dmesg for errors.

Raam · 2017-06-12 11:40:48

I proved beyond any reasonable doubt that the GPU is guilty. I ran the test glxspheres64 and got 60 frames/sec, 53 Mpixels/sec on a good system and 35 frames/sec, 33 Mpixels/sec on a bad system. I also noticed once when I ran the test right after resume, it was going good for a couple of seconds and then it slowed down.

I posted the output of dmesg right after boot here and the remaining bit right after resume here.

For information, the content of /etc/modprobe.d/i915.conf is

options i915 enable_rc6=1 enable_fbc=1 semaphores=1

as per arch wiki.

Strangely the output of systool -m i915 -av gives me semaphores = "0". But I admit I don't know what these options do.

The content of /etc/X11/xorg.conf.d/20-intel.conf is

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"
   Option "DRI" "3"
   Option "TearFree" "true"
EndSection

seth · 2017-06-12 20:47:09

Power saving. The IGP might have a wrong consideration about the power state (battery discharging, maybe considered "low"?) after returning from S3, so simply try to omitting the parameters and see whether that makes a difference.

Raam · 2017-07-13 08:32:42

Hi, sorry for being late. After an update and removing the file with the parameters, the problem persists.

Arch Linux

#1 2017-06-11 09:42:05

System slow after resume

#2 2017-06-11 14:40:55

Re: System slow after resume

#3 2017-06-11 16:04:36

Re: System slow after resume

#4 2017-06-11 16:21:25

Re: System slow after resume

#5 2017-06-11 22:48:53

Re: System slow after resume

#6 2017-06-12 05:55:18

Re: System slow after resume

#7 2017-06-12 11:40:48

Re: System slow after resume

#8 2017-06-12 20:47:09

Re: System slow after resume

#9 2017-07-13 08:32:42

Re: System slow after resume

Board footer