Laptop-mode v7 for linux 2.6.1
PATCH 1/1 Laptop-mode v7 for linux 2.6.1
I've created a new version of the laptop-mode patch, this time against linux 2.6.1. It can be found here:
http://www.liacs.nl/~bsamwel/laptop_mode/laptop-mode-2.6.1-7.patch
It has no kernel code changes, only changes to the supporting documentation/scripts:
* Dax Kelson's ACPI integration script is included.
* Fixed a missing "esac" in the control script.
* Minor documentation improvements.
Especially Dax's addition should make it a lot more usable. I haven't been able to test this myself however, because I don't own a laptop. Dax probably does, so I'll trust him and assume that he has tested it. ;)
-- Bart
Quoted 8 lines · Bart Samwel
I've created a new version of the laptop-mode patch, this time against linux 2.6.1. It can be found here:
http://www.liacs.nl/~bsamwel/laptop_mode/laptop-mode-2.6.1-7.patch
It has no kernel code changes, only changes to the supporting documentation/scripts:
Quoted 7 lines
* Dax Kelson's ACPI integration script is included.
* Fixed a missing "esac" in the control script.
* Minor documentation improvements.Especially Dax's addition should make it a lot more usable. I haven't been able to test this myself however, because I don't own a laptop. Dax probably does, so I'll trust him and assume that he has tested it. ;)
Indeed.
It works well, I've been using it on my laptop for the past few days.
Dax Kelson
Guru Labs
Quoted 8 lines · Bart Samwel
I've created a new version of the laptop-mode patch, this time against linux 2.6.1. It can be found here:
http://www.liacs.nl/~bsamwel/laptop_mode/laptop-mode-2.6.1-7.patch
It has no kernel code changes, only changes to the supporting documentation/scripts:
Quoted 7 lines
* Dax Kelson's ACPI integration script is included.
* Fixed a missing "esac" in the control script.
* Minor documentation improvements.Especially Dax's addition should make it a lot more usable. I haven't been able to test this myself however, because I don't own a laptop. Dax probably does, so I'll trust him and assume that he has tested it. ;)
There seems to be a typo in the battery.sh script. It
reads /proc/acpi/ac_adapter/AC/state to determine the AC Adaptor state, but this is in the ACAD directory instead of the AC directory.
Jan
Signature · 2 lines
The man on tops walks a lonely street; the "chain" of command is often a noose.
Quoted 1 line · Jan De Luyck
There seems to be a typo in the
battery.shscript. It reads/proc/acpi/ac_adapter/AC/stateto determine the AC Adaptor state, but this is in the ACAD directory instead of the AC directory.
Hmmm, Dax says it works for him, and I don't have an ac_adapter on my machine because I don't own a laptop. Dax, is this a typo or is it actually called AC on your machine?
-- Bart
Quoted 4 lines · Bart Samwel
I've created a new version of the laptop-mode patch, this time against linux 2.6.1. It can be found here:
http://www.liacs.nl/~bsamwel/laptop_mode/laptop-mode-2.6.1-7.patch
Patch applied, kernel built, laptop_mode activated, but my disk just doesn't want to spin down...
I have to activate it using ACPI BATT events, since my machine does not send out ACAD events. This is in /var/log/acpid:
[Mon Jan 12 11:26:18 2004] received event "battery BAT2 00000080 00000000" [Mon Jan 12 11:26:18 2004] executing action "/etc/acpi/battery.sh" [Mon Jan 12 11:26:18 2004] BEGIN HANDLER MESSAGES
Setting HD spindown to 20 seconds
Starting laptop_mode.
/dev/hda:
setting Advanced Power Management level to 0x01 (1) setting standby to 4 (20 seconds)
[Mon Jan 12 11:26:18 2004] END HANDLER MESSAGES [Mon Jan 12 11:26:18 2004] action exited with status 0 [Mon Jan 12 11:26:18 2004] completed event "battery BAT2 00000080 00000000"
Laptop mode is active:
$ cat /proc/sys/vm/laptop_mode 1
Commit values have been applied:
$ mount -t reiserfs /dev/hda6 on / type reiserfs (rw,noatime,notail,commit=600) /dev/hda7 on /home type reiserfs (rw,noatime,notail,commit=600)
But the disk never spins down. Not that I can tell, hdparm -C /dev/hda always tells me active/idle, and the sdsl tool also reports 100% disk spinning...
anything else I have to activate/check?
Signature · 2 lines
To err is human, to repent, divine, to persist, devilish. -- Benjamin Franklin
Quoted 1 line · Jan De Luyck
Patch applied, kernel built,
laptop_modeactivated, but my disk just doesn't want to spin down...
[...]
Quoted 3 lines
But the disk never spins down. Not that I can tell, hdparm -C
/dev/hdaalways tells me active/idle, and the sdsl tool also reports 100% disk spinning...anything else I have to activate/check?
Two things to try:
1. Check your HD with hdparm -I /dev/hdX, and see what it says at the "Standby timer values:" entry. Mine says:
Standby timer values: spec'd by Standard, with device specific minimum
In fact, when I set my HD to spin down in 20 seconds, it never spins down -- it's below the minimum. Try a higher value, or use my smart_spindown script instead (I posted this a while ago, with one of the laptop_mode patches).
2. Stop klogd, do "echo 1 > /proc/sys/vm/block_dump" and see which process keeps your disk spun up using dmesg.
Let me know if this helps.
-- Bart
Quoted 2 lines · Jan De Luyck
Patch applied, kernel built,
laptop_modeactivated, but my disk just doesn't want to spin down...
[...]
Quoted 4 lines
But the disk never spins down. Not that I can tell, hdparm -C
/dev/hdaalways tells me active/idle, and the sdsl tool also reports 100% disk spinning...anything else I have to activate/check?
As you don't say if you have checked it, here goes my suggestion:
First of all, you should assure there's no process doing reads [*] that cause a cache miss (eg. daemons like postfix that check the queue every few seconds). You can tell this running vmstat 1 and see that bi and bo [**] stay at 0.
For example, I've observed that fetchmail (using imaps protocol, with exim as mta) triggers a disk read that spins up the disk _always_ (regardless of what's in the cache). However, I must confess I have'nt tracked it down (or even looked at any source code).
[*] Processes making disk writes are supposed to be "harmless", because laptop-mode will delay those writes to disk (that's what it's supposed to do! ;).
[**] And that's why vmstat's bo is supposed to stay at 0.
Signature · 1 line
Kiko
On Monday 12 January 2004 12:22, Bart Samwel wrote:(
Quoted 10 lines
Quoted 2 lines · Jan De Luyck
Patch applied, kernel built,
laptop_modeactivated, but my disk just doesn't want to spin down...[...]
Quoted 4 lines
But the disk never spins down. Not that I can tell, hdparm -C
/dev/hdaalways tells me active/idle, and the sdsl tool also reports 100% disk spinning...
Quoted 8 lines
Quoted 1 line
anything else I have to activate/check?
Two things to try:
1. Check your HD with hdparm -I
/dev/hdX, and see what it says at the "Standby timer values:" entry. Mine says:Standby timer values: spec'd by Standard, with device specific minimum
Mine gives:
Standby timer values: spec'd by Vendor, no device specific minimum
(is an HITACHI_DK23EA-40)
Quoted 2 lines
smart_spindownscript instead (I posted this a while ago, with one of thelaptop_modepatches).
Will do.
Quoted 2 lines
2. Stop klogd, do "echo 1 >
/proc/sys/vm/block_dump" and see which process keeps your disk spun up using dmesg.
Welll.... i see no READs, and the writes i see is spamd, kmail, pdflush, reiserfs/0.
Jan
Signature · 3 lines
The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford
Quoted 6 lines · Kiko Piris
As you don't say if you have checked it, here goes my suggestion:
First of all, you should assure there's no process doing reads [*] that cause a cache miss (eg. daemons like postfix that check the queue every few seconds). You can tell this running vmstat 1 and see that bi and bo [**] stay at 0.
bi == 0 in 99% of the time. It caused one spinup sofar, and the disk has been spun op 10 times sofar.
Quoted 3 lines
[*] Processes making disk writes are supposed to be "harmless", because laptop-mode will delay those writes to disk (that's what it's supposed to do! ;).
Well, it looks otherwise to me.
Jan
Signature · 1 line
It's hard to keep your shirt on when you're getting something off your chest.
Quoted 8 lines · Bart Samwel
Quoted 3 lines · Jan De Luyck
There seems to be a typo in the
battery.shscript. It
reads/proc/acpi/ac_adapter/AC/stateto determine the AC Adaptor state, but this is in the ACAD directory instead of the AC directory.Hmmm, Dax says it works for him, and I don't have an
ac_adapteron my machine because I don't own a laptop. Dax, is this a typo or is it actually called AC on your machine?
On my Dell Inspiron 4150 it is called AC not ACAD.
Dax Kelson
Guru Labs
Quoted 5 lines · Dax Kelson
Quoted 3 lines
Quoted 1 line
There seems to be a typo in the
battery.shscript. It reads/proc/acpi/ac_adapter/AC/stateto determine the AC Adaptor state, but this is in the ACAD directory instead of the AC directory.Hmmm, Dax says it works for him, and I don't have an
ac_adapteron my machine because I don't own a laptop. Dax, is this a typo or is it actually called AC on your machine?On my Dell Inspiron 4150 it is called AC not ACAD.
Hmmmm. Does anybody have any idea why these names differ? Googling for acpi/ac_adapter gives me hits on a number of different programs that check for ac_adapter/*/state. I've seen AC, ACAD, 0 and 1 for names, so they're really pretty variable. So, a wildcard seems appropriate. Dax, if you agree, would you test + send in a patch to correct this? I can't do it myself because I can't test it. TIA!
-- Bart
Quoted 10 lines · Kiko Piris
Quoted 2 lines · Jan De Luyck
Patch applied, kernel built,
laptop_modeactivated, but my disk just doesn't want to spin down...[...]
Quoted 4 lines
But the disk never spins down. Not that I can tell, hdparm -C
/dev/hdaalways tells me active/idle, and the sdsl tool also reports 100% disk spinning...
Quoted 8 lines
Quoted 1 line
anything else I have to activate/check?
As you don't say if you have checked it, here goes my suggestion:
First of all, you should assure there's no process doing reads [*] that cause a cache miss (eg. daemons like postfix that check the queue every few seconds). You can tell this running vmstat 1 and see that bi and bo [**] stay at 0.
vmstat 1:
0 0 0 88748 37628 216216 0 0 0 0 1514 1130 7 4 89 0 0 0 0 88756 37628 216216 0 0 0 0 1495 1123 6 1 93 0 0 0 0 88748 37628 216216 0 0 0 0 1504 1114 8 4 88 0 1 0 0 88748 37628 216216 0 0 0 0 1499 1058 6 2 92 0 0 0 0 88748 37628 216216 0 0 0 0 1488 1062 7 4 89 0 0 0 0 88748 37628 216216 0 0 0 0 1480 1007 7 6 87 0 0 0 0 88876 37628 216216 0 0 0 0 1524 1122 7 6 87 0 0 0 0 88748 37628 216216 0 0 0 0 1506 1078 11 6 83 0 0 0 0 88748 37628 216216 0 0 0 0 1500 1057 11 5 84 0 0 0 0 88748 37628 216216 0 0 0 0 1514 1040 16 3 81 0 0 1 0 88748 37660 216216 0 0 0 28 1523 1041 19 4 64 13 0 1 0 88748 37660 216216 0 0 0 0 1500 994 23 2 0 75 0 0 0 88748 37660 216216 0 0 0 32 1540 1064 25 1 53 21 0 0 0 88748 37660 216216 0 0 0 0 1501 1064 24 0 76 0 0 0 0 88748 37660 216216 0 0 0 0 1514 1071 24 1 75 0 2 0 0 88812 37660 216216 0 0 0 0 1518 1086 24 1 75 0 0 0 0 88804 37660 216216 0 0 0 0 1504 1066 24 2 74 0 0 0 0 88740 37660 216216 0 0 0 0 1482 1015 25 1 74 0
At the presence of bo it spins up the disk.
Jan
Signature · 2 lines
Only fools are quoted. -- Anonymous
Quoted 4 lines · Jan De Luyck
Quoted 2 lines
2. Stop klogd, do "echo 1 >
/proc/sys/vm/block_dump" and see which process keeps your disk spun up using dmesg.Welll.... i see no READs, and the writes i see is spamd, kmail, pdflush, reiserfs/0.
How are the WRITEs grouped, are they grouped together or do they seem to occur more evenly spaced? When you use "sync", how long until the next WRITE? What are the values of /proc/sys/vm/dirty_expire_centisecs and /proc/sys/vm/dirty_writeback_centisecs? Are you sure you are running a kernel that supports the commit= option with reiserfs? (This option was added in 2.6.1.)
I've never tested laptop mode with reiserfs BTW, does anybody else here have experience with laptop mode and reiserfs?
-- Bart
Quoted 9 lines · On Mon, 12 Jan 2004 14:41:16 +0100 Bart Samwel <[email protected]> wrote:
How are the WRITEs grouped, are they grouped together or do they seem to occur more evenly spaced? When you use "sync", how long until the next WRITE? What are the values of
/proc/sys/vm/dirty_expire_centisecsand/proc/sys/vm/dirty_writeback_centisecs? Are you sure you are running a kernel that supports the commit= option with reiserfs? (This option was added in 2.6.1.)I've never tested laptop mode with reiserfs BTW, does anybody else here have experience with laptop mode and reiserfs?
Yes, I'm use reiserfs in 2.6.1 with laptop_mode patch. It works fine for me, I use cpudyn daemon to let spin download harddisk. In cpudyn.conf I changed TIMEOUT from 120 to 10. When i reading email/web, the harddisk can spin down for very long time (>3min).
So you can try cpudynd.
# TIMEOUT=120
TIMEOUT=10
#
# Specified disks to spindown (comma separated devices) #
# DISKS=/dev/hda,/dev/hdb
DISKS=/dev/hda
Signature · 3 lines
Hu Gang / Steve RLU# : 204016 [1999] (Registered Linux user) GPG Public Key: http://soulinfo.com/~hugang/HuGang.asc
Quoted 41 lines · Jan De Luyck
Quoted 10 lines · Kiko Piris
Quoted 2 lines · Jan De Luyck
Patch applied, kernel built,
laptop_modeactivated, but my disk just doesn't want to spin down...[...]
Quoted 4 lines
But the disk never spins down. Not that I can tell, hdparm -C
/dev/hdaalways tells me active/idle, and the sdsl tool also reports 100% disk spinning...Quoted 8 lines
Quoted 1 line
anything else I have to activate/check?
As you don't say if you have checked it, here goes my suggestion:
First of all, you should assure there's no process doing reads [*] that cause a cache miss (eg. daemons like postfix that check the queue every few seconds). You can tell this running vmstat 1 and see that bi and bo [**] stay at 0.
vmstat 1:
0 0 0 88748 37628 216216 0 0 0 0 1514 1130 7 4 89 0 0 0 0 88756 37628 216216 0 0 0 0 1495 1123 6 1 93 0 0 0 0 88748 37628 216216 0 0 0 0 1504 1114 8 4 88 0 1 0 0 88748 37628 216216 0 0 0 0 1499 1058 6 2 92 0 0 0 0 88748 37628 216216 0 0 0 0 1488 1062 7 4 89 0 0 0 0 88748 37628 216216 0 0 0 0 1480 1007 7 6 87 0 0 0 0 88876 37628 216216 0 0 0 0 1524 1122 7 6 87 0 0 0 0 88748 37628 216216 0 0 0 0 1506 1078 11 6 83 0 0 0 0 88748 37628 216216 0 0 0 0 1500 1057 11 5 84 0 0 0 0 88748 37628 216216 0 0 0 0 1514 1040 16 3 81 0 0 1 0 88748 37660 216216 0 0 0 28 1523 1041 19 4 64 13 0 1 0 88748 37660 216216 0 0 0 0 1500 994 23 2 0 75 0 0 0 88748 37660 216216 0 0 0 32 1540 1064 25 1 53 21 0 0 0 88748 37660 216216 0 0 0 0 1501 1064 24 0 76 0 0 0 0 88748 37660 216216 0 0 0 0 1514 1071 24 1 75 0 2 0 0 88812 37660 216216 0 0 0 0 1518 1086 24 1 75 0 0 0 0 88804 37660 216216 0 0 0 0 1504 1066 24 2 74 0 0 0 0 88740 37660 216216 0 0 0 0 1482 1015 25 1 74 0
Quoted 1 line
At the presence of bo it spins up the disk.
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use block_dump to find out why.
Signature · 1 line
Jens Axboe
Quoted 4 lines · Dax Kelson
Quoted 3 lines · Bart Samwel
Quoted 2 lines · Jan De Luyck
There seems to be a typo in the
battery.shscript. It
reads/proc/acpi/ac_adapter/AC/stateto determine the AC Adaptor state, b
ut
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
this is in the ACAD directory instead of the AC directory.
Hmmm, Dax says it works for him, and I don't have an
ac_adapteron my machine because I don't own a laptop. Dax, is this a typo or is it actually called AC on your machine?On my Dell Inspiron 4150 it is called AC not ACAD.
Dell Latitude C840 calls it /proc/acpi/ac_adapter/AC/state as well.
For the users of laptop-mode patch I find this entry in the manual page of syslog.conf very interesting:
"You may prefix each entry with the minus ‘‘-’’ sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner."
Found that after finding out that it was syslogd who spun up my disk:)
Signature · 1 line
Cioby
Quoted 3 lines · Jens Axboe
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use
block_dumpto find out why.
It's nearly always reiserfs that causes the disk to spin up. Also, I'm seeting the harddisk led light up every 5-7 seconds :-( weird.
Jan
Signature · 2 lines
I love you, not only for what you are, but for what I am when I am with you. -- Roy Croft
Quoted 7 lines · Jan De Luyck
Quoted 3 lines · Jens Axboe
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use
block_dumpto find out why.It's nearly always reiserfs that causes the disk to spin up. Also, I'm seeting the harddisk led light up every 5-7 seconds :-( weird.
Does 2.6 laptop mode patch even include the necessary reiser changes to make this work properly?
Signature · 1 line
Jens Axboe
Quoted 9 lines · Jens Axboe
Quoted 6 lines
Quoted 3 lines
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use
block_dumpto find out why.It's nearly always reiserfs that causes the disk to spin up. Also, I'm seeting the harddisk led light up every 5-7 seconds :-( weird.
Does 2.6 laptop mode patch even include the necessary reiser changes to make this work properly?
The reiserfs patch for "commit=" was included in Linux 2.6.1. I really don't know if it works with laptop mode, haven't tested it -- I don't use reiserfs. So, let's ask the world: is there anyone out there who is running laptop mode *successfully* with reiserfs?
-- Bart
Quoted 4 lines · On Tue, 13 Jan 2004 13:46:54 +0100 Bart Samwel <[email protected]> wrote:
The reiserfs patch for "commit=" was included in Linux 2.6.1. I really don't know if it works with laptop mode, haven't tested it -- I don't use reiserfs. So, let's ask the world: is there anyone out there who is running laptop mode *successfully* with reiserfs?
Yes, I'm use reiserfs in 2.6.1 with laptop_mode patch. It works fine for me, I use cpudyn daemon to let spin download harddisk. In cpudyn.conf I changed TIMEOUT from 120 to 10. When i reading email/web, the harddisk can spin down for very long time (>3min).
So you can try cpudynd.
# TIMEOUT=120
TIMEOUT=10
#
# Specified disks to spindown (comma separated devices) #
# DISKS=/dev/hda,/dev/hdb
DISKS=/dev/hda
For now, I switch to 2.6.1-mm2, it looks fine, not need any patch.
$mount/dev/hda13 on / type ext3 (rw,noatime,errors=remount-ro,commit=600) proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/vg00/opt on /opt type reiserfs (rw,noatime,commit=600) /dev/vg00/hugang on /home/hugang type reiserfs (rw,noatime,commit=600) /dev/vg00/scm on /scm type reiserfs (rw,noatime,commit=600) /dev/vg00/build on /build type reiserfs (rw,noatime,commit=600) none on /sys type sysfs (rw)
Signature · 3 lines
Hu Gang / Steve RLU# : 204016 [1999] (Registered Linux user) GPG Public Key: http://soulinfo.com/~hugang/HuGang.asc
Quoted 8 lines · Hugang
On Tue, 13 Jan 2004 13:46:54 +0100
Quoted 4 lines · Bart Samwel
The reiserfs patch for "commit=" was included in Linux 2.6.1. I really don't know if it works with laptop mode, haven't tested it -- I don't use reiserfs. So, let's ask the world: is there anyone out there who is running laptop mode *successfully* with reiserfs?
Quoted 6 lines
Yes, I'm use reiserfs in 2.6.1 with
laptop_modepatch. It works fine for me, I use cpudyn daemon to let spin download harddisk. In cpudyn.conf I changed TIMEOUT from 120 to 10. When i reading email/web, the harddisk can spin down for very long time (>3min).So you can try cpudynd.
Well, i used the smart-spindown script posted earlier, but even when not touching the laptop it gets a spindown of 40 seconds max. Then something always has to wake it up.
Quoted 1 line
/dev/hda13on / type ext3 (rw,noatime,errors=remount-ro,commit=600)
It is rather annoying that this commit parameter isn't documented anywhere... man mount doesn't know it, nor does the kernel documentation.
Jan
Signature · 2 lines
The executioner is, I hear, very expert, and my neck is very slender. -- Anne Boleyn
Quoted 11 lines · Jens Axboe
Quoted 7 lines · Jan De Luyck
Quoted 3 lines · Jens Axboe
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use
block_dumpto find out why.It's nearly always reiserfs that causes the disk to spin up. Also, I'm seeting the harddisk led light up every 5-7 seconds :-( weird.
Does 2.6 laptop mode patch even include the necessary reiser changes to make this work properly?
To followup on this: I've recently moved my entire installation to ext3 (I had to RMA the disk, tarred everything up, formatted another disk, put everything back but on ext3 this time), on which the laptopmode actually makes a difference. I can hear the disk spindown, and it stays that way for a reasonably long time (e.g. +- 10 minutes has happened).
So there does seem to be a serious difference between the reiserfs commit option and the ext3 option.
Just letting you folks know.
Jan
Signature · 2 lines
Baruch's Observation: If all you have is a hammer, everything looks like a nail.
Quoted 13 lines · Jan De Luyck
Quoted 11 lines · Jens Axboe
Quoted 7 lines · Jan De Luyck
Quoted 3 lines · Jens Axboe
bo is accounted when io is actually put on the pending queue for the disk, so they really do go hand in hand. So you should use
block_dumpto find out why.It's nearly always reiserfs that causes the disk to spin up. Also, I'm seeting the harddisk led light up every 5-7 seconds :-( weird.
Does 2.6 laptop mode patch even include the necessary reiser changes to make this work properly?
Quoted 9 lines
To followup on this: I've recently moved my entire installation to ext3 (I had to RMA the disk, tarred everything up, formatted another disk, put everything back but on ext3 this time), on which the laptopmode actually makes a difference. I can hear the disk spindown, and it stays that way for a reasonably long time (e.g. +- 10 minutes has happened).
So there does seem to be a serious difference between the reiserfs commit option and the ext3 option.
The reiserfs commit option doesn't work to suppress reiserfs journal writing to disk. The value that needs to be changes is the transaction max age instead of the commit max age which is being change now.
This is under work along with adding xfs support and fixing the ext3 commit option (there is no reset to default commit value option at the moment).
It won't take too long but if anyone is impatient I can send them a patch to fix reiserfs.
Quoted 14 lines
Just letting you folks know.
Jan
Signature · 8 lines
Baruch's Observation: If all you have is a hammer, everything looks like a nail. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/