I have a laptop with an Intel M5Y30. I value the ability of this processor to use less power and extend battery life when the CPU load is low. As this is a relatively new peocessor I chose to install Tumbleweed over Leap 42.2 back in December, in the hope that the later kernels would work better with this processor.
Tumbeweed has not been a problem, but after every reboot, when the initial CPU usage reduces to a system load averaging around 4 to 8% (from ksysguard.or top) then ksysguard still shows shows a CPU frequency around 2GHz, around the Maximum Turbo Boost range. And there it will stay with CPU core temps and frequencies and battery usage much higher than needed, for hours and hours. (stopped looking after about 5 hours).
This has been the case even since I installed Tumbleweed in December 2016, with the exception of the first Tumbleweed update to use a 4.8.x kernel.
HOWEVER, it has also always been the case that if I hibernate the system, and then bring it back, then almost immediately, frequencies will settle down to around 500MHz, along with a projected doubling of battery life and greatly reduces code temps. So this would seem to indicate that the kernel code (intel_pstate) can correctly commumicate reasonable intentions between the CPU and the kernel, and also that something is being set when the system comes out of hibernation, that isn’t happening on a reboot.
Any expertise on tracking this down with a view to having it fixed, so I can get the battery life benefits without a trip through hibernation?
off the top of my head, ideas for investigation:
1 - does TLP launch after boot (check journal) do you also get kernel message regards set to powersave after boot?
2 - run cpupower frequency-info after boot and again after hibernation (does suspend not also work?)
3 do same with cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
have you modified TLP config?
are you running the most recent bios for your laptop?
On Wed, 22 Mar 2017 20:26:02 +0000, mpaton1 wrote:
> I have a laptop with an Intel M5Y30. I value the ability of this
> processor to use less power and extend battery life when the CPU load is
> low. As this is a relatively new peocessor I chose to install Tumbleweed
> over Leap 42.2 back in December, in the hope that the later kernels
> would work better with this processor.
> Tumbeweed has not been a problem, but after every reboot, when the
> initial CPU usage reduces to a system load averaging around 4 to 8%
> (from ksysguard.or top) then ksysguard still shows shows a CPU frequency
> around 2GHz, around the Maximum Turbo Boost range. And there it will
> stay with CPU core temps and frequencies and battery usage much higher
> than needed, for hours and hours. (stopped looking after about 5 hours).
> This has been the case even since I installed Tumbleweed in December
> 2016, with the exception of the first Tumbleweed update to use a 4.8.x
> HOWEVER, it has also always been the case that if I hibernate the
> system, and then bring it back, then almost immediately, frequencies
> will settle down to around 500MHz, along with a projected doubling of
> battery life and greatly reduces code temps. So this would seem to
> indicate that the kernel code (intel_pstate) can correctly commumicate
> reasonable intentions between the CPU and the kernel, and also that
> something is being set when the system comes out of hibernation, that
> isn’t happening on a reboot.
> Any expertise on tracking this down with a view to having it fixed, so I
> can get the battery life benefits without a trip through hibernation?
I have a similar issue with an HP laptop with an I5 intel chip plus some
weird io stuff. One thing I notice is that booting with the power
adapter plugged in seems to lock all the cores at max frequency, If I
then pull the plug, the clock goes to its minimum speed and behaves until
the next boot. Booting on battery only seems to also eliminate the issue.
TW handling of this issue has been slowly improving but it’s pretty plain
that my problem lies with the acer-wmi module and hardware.
TLP did not launch after boot, or at any other time.
cpupower frequency-info seems to verify that ksysguard can be trusted
I do not claim to understand all aspects of the intel_pstate system, but I do accept that the use of governors is the old way, and has been replaced by the intel_pstate driver in the kernel, provided one has a recent enough processor, which I do.
I haven’t modified the config of TLP, and I don’t believe TLP is relevant.
I haven’t tried suspend recently, but I don’t think it changed anything.
And yes, on the most recent bios.
I think I need help from someone with a deep understanding of the intel_pstate system, and also what SuSE does on boot and on coming out of hibernation.
But thanks anyway, I think your suggestions would have been useful on several of my older laptops. But things have changed. I had been intent on diving into the kernel code, but then I discovered this change if I hibernate, and I believe looking at this will get me to an answer sooner. Probably not so educational though.
hmmm - to clarify
i said to use cpupower frequency-info to check the driver (pstate or cpugov) not the frequency.
pstate is run by hardware with single directive of either powersave or performance - hence the need to determine the driver and the directive after boot and after hibernation.
TLP is relevant since it is switched on by default on TW and because its activated after boot and before after hibernation and controls the directive - hence it could be a prime factor.
but when “idle”, powertop shows that all 8 cpu cores are indeed “idle” some 99% of the time and apparently switch to “top gear” almost instantly when needed.
When I boot the 4.10.3 kernel, when the system is “idle” I see a different frequency picture apparently:
but powertop shows 8 cores “idle” some 99% of the time and battery drain about 11 W with no noticeable diference to the 4.4 kernel.
No noticeable difference switching the mains adapter on or off, suspending to ram or to disk.
For the records, this i7 4720HQ CPU is driven by the intel_pstate driver with both kernels.
LT_B:~ # cpupower frequency-info
analyzing CPU 0:
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: 800 MHz - 3.60 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3.60 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: 3.56 GHz (asserted by call to hardware)
boost state support:
tlp is run on boot, but not on resume from hibernation.
When it is run at boot time, it fails with exitcode=4, which comes from the apply_common_settings() function, specifically the
case “$mode” in statement when mode is auto. this is how it is invoked by systemd according to journalctl.
auto appears to be an undocumented argument, at least so far.
tlp-stat run after boot and after resume from hibernation shows no differences, aside from battery levels, and times.
cpupower frequency-info agrees with tlp
tlp-stat shows the scaling governor as powersave and the scaling driver as intel_pstate
tlp-stat also complains that tlp.service and tlp-sleep.service are not enabled, and that systemd-rfkill.service is not masked.
so you have established that after boot and after resume you have the same driver with the same directive (but problem=different cpu behaviours).
TLP is almost a separate issue at this point (its the /sys parameter settings that count, not how they get set), but on the subject of tlp i did change some of the settings, certainly mask of systemd-rfkill.service, i think i enabled services but cannot remember,
you should check sudo systemctl status tlp tlp-sleep (mine are enabled with lots of activity) (if not running, its simple to enable: http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html <service units>)
tlp exit code -4 is a red herring - its normal behaviour
have noted in passing, threads describing pathological behaviour of pstates and users changing to kernel governer but since your system do work most of the time i doubt this is relevant.
OrsoBruno - im not clear on the point your making. ps my system uses 4.2 watts - you must have a monster at 11w!
Yes, but more importantly, the boot behaviour is the problem, and the port hibernate behaviour is the desired one.
And this is why I’m reluctant to mess with tlp. I could make it do more, but it doesn’t seem to do much at the moment, and making it do more around sleep time doesn’t look like it would fix my problem. I’m a bit surprised not to have found more on the forums. This should be a battery life problem with any laptop with a SkyLake or KabyLake processor.
So what do you think tlp ought to be doing prior to aborting with exitcode=4. Apart from a few initializations, it doesn’t look like much.
The point I’m trying to make is: what counts is actual power consumption, not reported frequency. With my setup, higher reported frequency doesn’t translate to higher battery drain, apparently.
And I don’t see any relevant difference (other than reported frequency) in tlp-stat or system logs when changing kernel from 4.4.x to 10.0.3.
That said, the OP witnessed half the power drain after suspend according to post #1, so apparently there is room for improvement with that HW.
But if tlp-stat shows something like I see here:
then no wonder that the system runs near the turbo max frequency most of the time IMHO.
BTW, I don’t run a monster, just a “desktop replacement” notebook with known problems that prevent the system to reach the deeper system sleep states with Linux drivers.
Not so many SkyLakes or KabyLakes on openSUSE out here yet, apparently.
> And this is why I’m reluctant to mess with tlp. I could make it do more, but it doesn’t seem to do much at the moment, and making it do more
> around sleep time doesn’t look like it would fix my problem. I’m a bit surprised not to have found more on the forums. This should be a
> battery life problem with any laptop with a SkyLake or KabyLake processor.
not sure what you mean here, im on skylake (with TW) and it functions perfectly, low frequencies, reaches lowest pstates etc (9 hr battery life)
since the (your) current TLP setup is confusing (Im not sure if its a misconfiguration or not) I would finish the setup (services and mask) as previously described, reboot and see what happens - its easy enough to reverse the steps (disable and unmask)
> So what do you think tlp ought to be doing prior to aborting with exitcode=4. Apart from a few initializations, it doesn’t look like much.
not sure what your getting at, TLP ought to be doing what TLP does. The exit code is due to the way TLP works, im not totally clear but it is invoked rather than being a deamon, it exits when invoked when its already running, its by design.
/sys/devices/system/cpu/intel_pstate/turbo_pct=74 for me, it means nothing - reports limits
there is not much i can add, hopefully somebody with more knowledge can help.
I have a default TW install. You, it appears, do not. Foolishly perhaps, I expect my default install to “just work”.
My current TLP setup may well be confusing, but it is completely unmodified. And anything my TLP ISN’T doing, is not affecting the issues I’m having. Assuming that journalctl reveals when it is invoked.
TLP is a bash script. Traditionally, non zero exit codes are aborts. So my TLP is exiting abnormally. It appears you think it exits with this code because it’s already running? If so, where do you think it is started from? Obviously systemd somehow, but where?
I don’t think TLP is much to do with my problem. What I’m asking you, is what you think the Tumbleweed expects to achieve by invoking TLP at all, and why it is invoked with an undocumented option, namely “auto”. As to what TLP does, its web site doesn’t have much at all to say about what it does for CPU p states, and quite a lot about battery settings, mostly for Thinkpads.
And why do you think TLP has much at all to do with my issue. After all, it’s a script, so we can both look at what’s being done. You’ve been insistent that I have a TLP issue caused by something I’ve done or not done with TLP. And while you may be right, I’m not seeing it. How do you have TLP called? Does your TLP exit with a non-zero code? Which Skylake processor do you have? Maybe that makes a difference. Supposedly some of the features that intel_pstate relies on are enabled by a whitelist of CPUs. Maybe mine isn’t included.
i ran around this after install - got the messages you got from TLP regarding services - checked arch wiki etc and went forward with their recommendations - appears to work well. The problem, that i have never pursued, is that TLP appears ‘half’ installed on TW such that i am uncertain of its behaviour (if you have checked the journal your likely correct that you can ignore for the case in point - but if it isnt running you will not get good battery life). The thinkpad stuff is not relevant (they come up on anything power related) - TLP can affect anything to do with powersaving (the tunable parameters you see in powertop for example) hence it has some relevance (but its the parameters that count not how they get set). The -4 exit code i briefly researched and found an explanation regards double invokes as explained, i just looked at TLP in /usr/sbin. ‘auto’ is the mode when invoked by udev, the exit code appears (at first glance) not an error but the logic is not clear. yes TLP is invoked by systemd but also by udev.
to explain my original intentions “to ‘diff’ between the working on broken states”
> Foolishly perhaps, I expect my default install to “just work”.
if a single issue regards pstates leaves you disappointed you have very high expectations.