Improving Linux laptop battery life: Testers Wanted

[Hans de Goede]

Hi All,

My next project for Red Hat is to work on improving Linux laptop battery life.
Part of the (hopefully) low hanging fruit here is using kernel tunables to
enable more runtime powermanagement. My first target here is SATA Link Power
Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
https://mjg59.dreamwidth.org/34868.html
can lead to a significant improvement in battery life.

There is only one small problem, there have been some reports that some
disks/SSDs don't play well with Linux' min_power LPM policy and that this
may lead to system crashes and even data corruption.

As such I've written a new LPM policy, which matches the power-management
defaults from the Intel RST Windows drivers. Since it mimicks Windows,
this new policy will hopefully not hit any SSD firmware bugs like min_power
sometimes does.

So now I'm looking for people with a laptop with a SATA SSD or HDD to help
me test this to make sure this won't cause any issues when we enable this
by default for F28, for more details and test instructions see:

https://hansdegoede.livejournal.com/18412.html

Regards,

Hans

[Germano Massullo]

Hi Hans, I can provide ~10 different Thinkpad models to test your code.
Looking forward to start!
Have a nice day

[Hans de Goede]

Hi,

On 14-09-17 14:44, Germano Massullo wrote:
>  Hi Hans, I can provide ~10 different Thinkpad models to test your
> code.
>  Looking forward to start! 
That is great, thank you.

I'm looking forward to hear back from you with the results.

Regards,

Hans

[Germano Massullo]

Il 17/09/2017 15:39, Hans de Goede ha scritto:
>  Hi,
>
>  On 14-09-17 14:44, Germano Massullo wrote:
> > Hi Hans, I can provide ~10 different Thinkpad models to test your code.
> > Looking forward to start!
>
>  That is great, thank you.
>
>  I'm looking forward to hear back from you with the results.
>
>  Regards,
>
>  Hans
>  
Just a question before I start with tests on some machines. Concerning
the very little probability that some data corruption could happen:
which kind of data corruption would be? Bit flips, etc. Yes I do have
backups, but I wanted to ask that just to understand if I better to
resume data from backups even if I had no apparent crashes during tests.

Have a nice day

[Hans de Goede]

Hi,

On 17-09-17 17:26, Germano Massullo wrote:
>  Il 17/09/2017 15:39, Hans de Goede ha scritto:
> > Hi,
> >
> > On 14-09-17 14:44, Germano Massullo wrote:
> >> Hi Hans, I can provide ~10 different Thinkpad models to test your code.
> >> Looking forward to start!
> >
> > That is great, thank you.
> >
> > I'm looking forward to hear back from you with the results.
> >
> > Regards,
> >
> > Hans
> >
>  Just a question before I start with tests on some machines. Concerning
>  the very little probability that some data corruption could happen:
>  which kind of data corruption would be? Bit flips, etc. Yes I do have
>  backups, but I wanted to ask that just to understand if I better to
>  resume data from backups even if I had no apparent crashes during tests. 
There are 2 sorts of problems which have been reported in the past:

1) The disk stops responding, so the system is effectively dead
until you reboot, with a journaling filesystem this should not be a
problem really. This is the most frequent problem (still not very
frequent).

2) Some SSD firmwares seem to mess up their internal bookkeeping
of which part of the flash holds what when putting the SSD in a low
power state at just the wrong time. This typically lead to all sort
of filesystem errors, etc. and requires a full re-install. This is
a very rare occurrence, but is the reason why I've been asking for
wide testing as this one is nasty.

TL;DR: I do not expect you to see any silent data corruption if
anything goes wrong, you should know.

Note hitting the race for problem 2. may take some time, which is why
I've asked people to test with the patched kernel and the
med_power_with_dipm policy for at least 2 weeks.

Regards,

Hans

[Germano Massullo]

Thank you for the extensive explanation!
>  TL;DR: I do not expect you to see any silent data corruption if
>  anything goes wrong, you should know. 
Ok, at the end of each day I will give a look to "dmesg", just to be
sure that everything went fine.
I will also check for firmware updates before starting the tests.

A few questions/statements:
1) is it okay to run the tests with the power cord plugged? Or do I need
to use battery in order to trigger such kind of power saving features?
2) In your guide you specified "[...] on a clean Fedora". I actually
cannot run a new Fedora installation on my SSDs, but I haven't messed up
with any kind of strange powersaving features, so it should be fine to
use my regular Fedora installation for the tests. Do you confirm? To be
sure, I will attach to test results e-mail, also:
- /etc/fstab
- /proc/cmdline
- # lshw
3) Since in these days I am not using much the Thinkpads, I think I will
run Phoronix suite in order to simulate machine activity
Among all Phoronix test suite tests, If you think that there are some
that best fit your case, please let me know. To read a list of disk
oriented benchmarks, you can do:
# dnf install phoronix-test-suite
$ phoronix-test-suite list-available-tests | grep Disk


Best regards

[Hans de Goede]

Hi,

Germano Massullo wrote:

>  Thank you for the extensive explanation!
>
>  Ok, at the end of each day I will give a look to "dmesg", just to be
>  sure that everything went fine.
>  I will also check for firmware updates before starting the tests.
>
>  A few questions/statements:
>  1) is it okay to run the tests with the power cord plugged? Or do I need
>  to use battery in order to trigger such kind of power saving features? 
Running the tests with the power cord plugged in is fine, but to get
info on how much power this actually saves you need to be running on
battery since most laptops can only measure power-consumption while
running on battery. After getting the initial idle and idle power
consumption with the new med_power_with_dipm policy activated you
can run with the cord plugged in.

>  2) In your guide you specified "[...] on a clean Fedora". I
> actually
>  cannot run a new Fedora installation on my SSDs, but I haven't messed up
>  with any kind of strange powersaving features, so it should be fine to
>  use my regular Fedora installation for the tests. Do you confirm? 
Yes that is fine.

>  To be
>  sure, I will attach to test results e-mail, also:
>  - /etc/fstab
>  - /proc/cmdline
>  - # lshw
>  3) Since in these days I am not using much the Thinkpads, I think I will
>  run Phoronix suite in order to simulate machine activity
>  Among all Phoronix test suite tests, If you think that there are some
>  that best fit your case, please let me know. To read a list of disk
>  oriented benchmarks, you can do:
>  # dnf install phoronix-test-suite
>  $ phoronix-test-suite list-available-tests | grep Disk 
Sounds good.

Regards,

Hans

[Germano Massullo]

This message may be useful to others having my similar problem.
On a Thinkpad X220, after having booted the custom kernel, running

[root@machine]# cat /sys/class/scsi_host/host0/link_power_management_policy

I get

max_performance

instead of

med_power_with_dipm


Here some machine details

[root@machine]# cat /etc/rc.d/rc.local
#!/bin/sh

for i in /sys/class/scsi_host/host*/link_power_management_policy; do
    echo med_power_with_dipm > $i
done


[root@machine]# ls -latr /etc/rc.d/rc.local
-rwxrwxr-x. 1 user user 119 13 set 14.53 /etc/rc.d/rc.local


[root@machine]# cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz


[root@machine]# cat /sys/class/scsi_device/*/device/model
Samsung SSD 850
(it is a Samsung 850 PRO)

[Germano Massullo]

This message may be useful to others having my similar problem.
On a Thinkpad X220, after having booted the custom kernel, running

[root@machine]# cat /sys/class/scsi_host/host0/link_power_management_policy

I get

max_performance

instead of

med_power_with_dipm


Here some machine details

[root@machine]# cat /etc/rc.d/rc.local
#!/bin/sh

for i in /sys/class/scsi_host/host*/link_power_management_policy; do
    echo med_power_with_dipm > $i
done


[root@machine]# ls -latr /etc/rc.d/rc.local
-rwxrwxr-x. 1 user user 119 13 set 14.53 /etc/rc.d/rc.local


[root@machine]# cat /proc/cpuinfo | grep "model name"
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz


[root@machine]# cat /sys/class/scsi_device/*/device/model
Samsung SSD 850
(it is a Samsung 850 PRO)

[Hans de Goede]

Hi,

On 26-09-17 16:59, Germano Massullo wrote:
>  This message may be useful to others having my similar problem.
>  On a Thinkpad X220, after having booted the custom kernel, running
>  
>  [root@machine]# cat /sys/class/scsi_host/host0/link_power_management_policy
>  
>  I get
>  
>  max_performance
>  
>  instead of
>  
>  med_power_with_dipm
>  
>  
>  Here some machine details
>  
>  [root@machine]# cat /etc/rc.d/rc.local
>  #!/bin/sh
>  
>  for i in /sys/class/scsi_host/host*/link_power_management_policy; do
>       echo med_power_with_dipm > $i
>  done
>  
>  
>  [root@machine]# ls -latr /etc/rc.d/rc.local
>  -rwxrwxr-x. 1 user user 119 13 set 14.53 /etc/rc.d/rc.local 
It might be that systemd does not like that rc.local is owned
by "user" rather then "root" ? Have you tried manually
executing rc.local as root:

/etc/rc.d/rc.local

And / or have you tried to do the echo manually as root ?

Regards,

Hans

[Germano Massullo]

>  It might be that systemd does not like that rc.local is owned
>  by "user" rather then "root" 
Unfortunately
# chown root:root /etc/rc.d/rc.local
did not solve the problem, instead manually running the script as root,
changed the
/sys/class/scsi_host/host0/link_power_management_policy
state to
med_power_with_dipm

In powertop I noticed a saving of ~1 Watt. I will send you complete test
results as you requested in
https://hansdegoede.livejournal.com/18412.html

For people who wants to stress the disk:

# dnf install phoronix-test-suite
$ phoronix-test-suite install disk
$ phoronix-test-suite run disk

I will run disk suite tests many times per day for 2 weeks

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 27, 2017 at 11:54:29PM +0200, Germano Massullo wrote:
>  
>  > It might be that systemd does not like that rc.local is owned
>  > by "user" rather then "root"
>  Unfortunately
>  # chown root:root /etc/rc.d/rc.local
>  did not solve the problem, instead manually running the script as root,
>  changed the
>  /sys/class/scsi_host/host0/link_power_management_policy
>  state to
>  med_power_with_dipm 
(No idea why rc.local is not working for you.)

A simpler option might be to use add a tmpfiles.d entry:

# /etc/tmpfiles.d/sata.conf 
w /sys/class/scsi_host/host*/link_power_management_policy - - - - med_power_with_dipm

Zbyszek

[Kevin Fenzi]

On 09/14/2017 04:22 AM, Hans de Goede wrote:
>  Hi All,
>  
>  My next project for Red Hat is to work on improving Linux laptop battery
>  life.
>  Part of the (hopefully) low hanging fruit here is using kernel tunables to
>  enable more runtime powermanagement. My first target here is SATA Link
>  Power
>  Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
>  https://mjg59.dreamwidth.org/34868.html
>  can lead to a significant improvement in battery life.
>  
>  There is only one small problem, there have been some reports that some
>  disks/SSDs don't play well with Linux' min_power LPM policy and that this
>  may lead to system crashes and even data corruption.
>  
>  As such I've written a new LPM policy, which matches the power-management
>  defaults from the Intel RST Windows drivers. Since it mimicks Windows,
>  this new policy will hopefully not hit any SSD firmware bugs like min_power
>  sometimes does.
>  
>  So now I'm looking for people with a laptop with a SATA SSD or HDD to help
>  me test this to make sure this won't cause any issues when we enable this
>  by default for F28, for more details and test instructions see:
>  
>  https://hansdegoede.livejournal.com/18412.html 
Hey Hans. I had marked this to try and do to help gather info, but
things have been busy and I haven't ever gotten to it.

I thought before I did I might ask if you already have the info you were
looking for since it's been over a month now.

How have reports been? Is it perhaps time to enable this in rawhide?

kevin

[Hans de Goede]

Hi,

On 21-10-17 20:50, Kevin Fenzi wrote:
>  On 09/14/2017 04:22 AM, Hans de Goede wrote:
> > Hi All,
> >
> > My next project for Red Hat is to work on improving Linux laptop battery
> > life.
> > Part of the (hopefully) low hanging fruit here is using kernel tunables to
> > enable more runtime powermanagement. My first target here is SATA Link
> > Power
> > Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
> > https://mjg59.dreamwidth.org/34868.html
> > can lead to a significant improvement in battery life.
> >
> > There is only one small problem, there have been some reports that some
> > disks/SSDs don't play well with Linux' min_power LPM policy and that this
> > may lead to system crashes and even data corruption.
> >
> > As such I've written a new LPM policy, which matches the power-management
> > defaults from the Intel RST Windows drivers. Since it mimicks Windows,
> > this new policy will hopefully not hit any SSD firmware bugs like min_power
> > sometimes does.
> >
> > So now I'm looking for people with a laptop with a SATA SSD or HDD to help
> > me test this to make sure this won't cause any issues when we enable this
> > by default for F28, for more details and test instructions see:
> >
> > https://hansdegoede.livejournal.com/18412.html
>  
>  Hey Hans. I had marked this to try and do to help gather info, but
>  things have been busy and I haven't ever gotten to it.
>  
>  I thought before I did I might ask if you already have the info you were
>  looking for since it's been over a month now.
>  
>  How have reports been? Is it perhaps time to enable this in rawhide? 
I've had successful test reports from 10 people, of which 1 person
was actually seeing data corruption on his ssd with min_power and not
with the new med_power_with_dipm policy my patches add, which is good
news really :)

But 10 testers is not that much, so if you still feel like testing this,
then some more testing would definitely be welcome.

Regards,

Hans

[Chris Murphy]

On Mon, Oct 23, 2017, 3:13 PM Hans de Goede <hdegoede(a)redhat.com&gt; wrote:

>  Hi,
>
>  On 21-10-17 20:50, Kevin Fenzi wrote:
>  > On 09/14/2017 04:22 AM, Hans de Goede wrote:
>  >> Hi All,
>  >
> >  
>  >> My next project for Red Hat is to work on improving
> Linux laptop battery
>  >> life.
>  >> Part of the (hopefully) low hanging fruit here is using kernel tunables
>  to
>  >> enable more runtime powermanagement. My first target here is SATA Link
>  >> Power
>  >> Management (LPM) which, as Matthew Garrett blogged about 2 years ago:
>  >> https://mjg59.dreamwidth.org/34868.html
>  >> can lead to a significant improvement in battery life.
>  >
> >  
>  >> There is only one small problem, there have been some
> reports that some
>  >> disks/SSDs don't play well with Linux' min_power LPM policy and that
>  this
>  >> may lead to system crashes and even data corruption.
>  >
> >  
>  >> As such I've written a new LPM policy, which
> matches the
>  power-management
>  >> defaults from the Intel RST Windows drivers. Since it mimicks Windows,
>  >> this new policy will hopefully not hit any SSD firmware bugs like
>  min_power
>  >> sometimes does.
>  >
> >  
>  >> So now I'm looking for people with a laptop with
> a SATA SSD or HDD to
>  help
>  >> me test this to make sure this won't cause any issues when we enable
>  this
>  >> by default for F28, for more details and test instructions see:
>  >
> >  
>  >> https://hansdegoede.livejournal.com/18412.html
> >  
>  > Hey Hans. I had marked this to try and do to help gather
> info, but
>  > things have been busy and I haven't ever gotten to it.
> >  
>  > I thought before I did I might ask if you already have
> the info you were
>  > looking for since it's been over a month now.
> >  
>  > How have reports been? Is it perhaps time to enable this
> in rawhide?
>
>  I've had successful test reports from 10 people, of which 1 person
>  was actually seeing data corruption on his ssd with min_power and not
>  with the new med_power_with_dipm policy my patches add, which is good
>  news really :)
>
>  But 10 testers is not that much, so if you still feel like testing this,
>  then some more testing would definitely be welcome.
>  
I'm curious what the manifestation of corruption is, and whether any on the
10 were using Btrfs?


Chris Murphy

>

[Germano Massullo]

Hi Hans, do you have any F27 kernel to test SATA Link Power Management
(LPM)?
Best regards