3

I own a Dell XPS 9370 laptop with an i7 8550U.

I recently noticed, that my performance decreases quite significantly when my battery percentage drops under 20%. This especially visible on GNOMEs animations, which start to get pretty laggy. This happens in all Ubuntu versions from 18.04 to 19.10 I tested.

I tried to investigate a bit and observed that my CPU frequency does not scale up properly anymore, it does not reach the max frequency of my processor (4 GHz) by far after my battery life falls under 20%. When running with over 20%, it scales properly up to the 4 GHz.

Setting the CPU governor to performance removes that impact but is obviously not a solution, as that has a serious impact on the battery life.

So all in all it feels like a power saving feature of the governor. Is there a possibility to turn it off or move the battery percentage that kicks in? Maybe some kernel parameter?
Any additional ideas to solve that problem?

Cheers in advance

P.S: I uninstalled all additional power saving tools I know of (tlp etc.), but that did not help either.

InvisibleShadowGhost
  • 721
  • This is not a kernel thing, nor anything to do with any governor. As far as I know, it is a Dell thing. When under 20% battery what do you get for cat /sys/devices/system/cpu/intel_pstate/max_perf_pct and cat /sys/devices/system/cpu/intel_pstate/no_turbo? – Doug Smythies Nov 11 '19 at 22:41
  • @DougSmythies Good to know. Those are the values for over 20%: cat /sys/devices/system/cpu/intel_pstate/max_perf_pct returns 100 and cat /sys/devices/system/cpu/intel_pstate/no_turbo returns 0.

    I will add those for under 20% after my battery life dropped...

     – InvisibleShadowGhost Nov 11 '19 at 22:53
  • Low battery situations dictate shutting off powerr to subsystems. Then when they are accessed power up introduces more latency. That's my guess. – WinEunuuchs2Unix Nov 11 '19 at 23:04
  • Dell forces "clock modulation" via the BIOS under some circumstances, this might be one of them. To determine for certain see here. And note: you may find around here comments from me saying "the intel_pstate CPU frequency driver is fundamentally incompatible with clock modultion". That is no longer true, but it will limit your max frequency. – Doug Smythies Nov 11 '19 at 23:10
  • @InvisibleShadowGhost : I missed that you mentioned "for over 20%". Only look into clock modulation if the other numbers stay after battery < 20%. – Doug Smythies Nov 12 '19 at 00:43
  • Just checked it this morning and yeah, they stay the same under 20%. – InvisibleShadowGhost Nov 12 '19 at 07:48
  • @DougSmythies So, looked into the clock modulation today. But unfortunately, the output of sudo rdmsr -a 0x19a stays 0 even if its under 20% and throttled. So that might not be the reason... – InvisibleShadowGhost Nov 13 '19 at 22:46
  • @InvisibleShadowGhost : O.K. so I seem to have wasted your time. The only other thing I can think of is via this path: /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq. Depending on your kernel version, the two methods may or may not be interlinked. – Doug Smythies Nov 13 '19 at 22:56
  • @DougSmythies You did not have wasted my time at all! Thanks for your support and the time you invested and I am really sorry if my respond sounded rude :( – InvisibleShadowGhost Nov 13 '19 at 22:57
  • @InvisibleShadowGhost : Not at all, and actually thanks for even replying, as a very very high percentage of posters we never hear back from and are left wondering, as are future readers. – Doug Smythies Nov 13 '19 at 22:59
  • @DougSmythies Alright. And I had a look into the /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq, which stays 4000000 even if throttled. So it looks like, that might not be the reason either... By the way, currently running the 5.3 kernel. – InvisibleShadowGhost Nov 13 '19 at 23:09
  • @WinEunuuchs2Unix What are the subsystems you think about? Do you have any idea how to check? – InvisibleShadowGhost Nov 13 '19 at 23:13
  • @InvisibleShadowGhost : Hmmm... this one is interesting. While it doesn't make sense, I wonder about idle injection (either old way with kidle_inject, or the new way with idle_inject (only the hooks are supposed to be in place for the new way so far, I think)). One way to check would be via top and or via ps aux. – Doug Smythies Nov 13 '19 at 23:49
  • @DougSmythies (and Ghost) I was thinking powering off HDD or SSD which could explain performance drop. Besides being powered off some devices have sleep states. The USB bus is another power drain. You could check dmesg as soon as you notice system slowing down. Probably at the same time you should notice the screen getting dimmer? – WinEunuuchs2Unix Nov 14 '19 at 00:09
  • @DougSmythies That sounds interesting. Could you be a bit more specific on how test/observe whether that is the case? – InvisibleShadowGhost Nov 16 '19 at 23:19
  • @WinEunuuchs2Unix I actually do not experience screen dimming, only a performance drop... For which entries would I like in dmesg? – InvisibleShadowGhost Nov 16 '19 at 23:20
  • @InvisibleShadowGhost : I would use top, and then observe a lot of CPU time allocated to kidle_inject tasks, one task per CPU. You might also see idle_inject, but they should still be at 0% CPU, because as far as I know they are only hooks so far for future use. Otherwise, we'll have to move to a chat, as further investigation will be somewhat complicated, requiring some back and forth. – Doug Smythies Nov 17 '19 at 00:58
  • @DougSmythies Alright, I will have a look into it when my battery is going down again. And yes, your idea of switching to a messenger sounds great, just tell me which one you prefer :) – InvisibleShadowGhost Nov 17 '19 at 11:04
  • @DougSmythies Battery life dropped and performance throttled again. But htop does not return any process when I filter for idle...

    Furthermore, dmesg -T shows the last entry with a timestamp from two hours ago...

     – InvisibleShadowGhost Nov 17 '19 at 14:19
  • @InvisibleShadowGhost : If you are willing, it is time to try turbostat, and to start looking directly at the p-state requested and p-state granted registers. turbostat (linux-tools-common package) can spew a bunch of stuff at startup that may or may not help. As a starting point suggest: sudo turbostat --Summary --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 15. The pstate requested/granted MSRs are via sudo rdmsr --bitfield 15:8 -d -a 0x199 and sudo rdmsr --bitfield 15:8 -d -a 0x198. This thiing will automatically ask us to move to chat, eventually. – Doug Smythies Nov 17 '19 at 15:06
  • @InvisibleShadowGhost : Oh, and by the way, you might find that using the performance governor is not all that expensive in terms of energy. Yes, the CPU frequency ramps up faster, but also the job gets done faster resulting in more time in deep idle states. The cost on my very idle server is 0.8%. – Doug Smythies Nov 17 '19 at 15:22
  • Let us continue this discussion in chat. – Doug Smythies Nov 17 '19 at 15:34

0 Answers0