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
On Sat, 2004-01-10 at 03:38, Bart Samwel wrote:
> 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. ;)
Indeed.
It works well, I've been using it on my laptop for the past few days.
Dax Kelson
Guru Labs
On Saturday 10 January 2004 11:38, Bart Samwel wrote:
> 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. ;)
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
--
The man on tops walks a lonely street; the "chain" of command is often a
noose.
Jan De Luyck wrote:
> 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.
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
On Saturday 10 January 2004 11:38, Bart Samwel wrote:
> 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?
--
To err is human, to repent, divine, to persist, devilish.
-- Benjamin Franklin
Jan De Luyck wrote:
> Patch applied, kernel built, laptop_mode activated, but my disk just doesn't
> want to spin down...
[...]
> 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?
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
On 12/01/2004 at 12:12, Jan De Luyck wrote:
> Patch applied, kernel built, laptop_mode activated, but my disk just doesn't
> want to spin down...
[...]
> 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?
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.
--
Kiko
On Monday 12 January 2004 13:19, Kiko Piris wrote:
> 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.
> [*] 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
--
It's hard to keep your shirt on when you're getting something off your chest.
On Mon, 2004-01-12 at 02:59, Bart Samwel wrote:
> Jan De Luyck wrote:
> > 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.
>
> 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?
On my Dell Inspiron 4150 it is called AC not ACAD.
Dax Kelson
Guru Labs
On Monday 12 January 2004 12:22, Bart Samwel wrote:(
> Jan De Luyck wrote:
> > Patch applied, kernel built, laptop_mode activated, but my disk just
> > doesn't want to spin down...
>
> [...]
>
> > 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?
>
> 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)
> smart_spindown script instead (I posted this a while ago, with one of
> the laptop_mode patches).
Will do.
> 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
--
The only possible interpretation of any research whatever in the `social
sciences' is: some do, some don't.
-- Ernest Rutherford
Dax Kelson wrote:
>>>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.
>>
>>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?
>
> 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
On Monday 12 January 2004 13:19, Kiko Piris wrote:
> On 12/01/2004 at 12:12, Jan De Luyck wrote:
> > Patch applied, kernel built, laptop_mode activated, but my disk just
> > doesn't want to spin down...
>
> [...]
>
> > 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?
>
> 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
--
Only fools are quoted.
-- Anonymous
Jan De Luyck wrote:
>>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
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_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?
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
--
Hu Gang / Steve
RLU# : 204016 [1999] (Registered Linux user)
GPG Public Key: http://soulinfo.com/~hugang/HuGang.asc
On Mon, Jan 12 2004, Jan De Luyck wrote:
> On Monday 12 January 2004 13:19, Kiko Piris wrote:
> > On 12/01/2004 at 12:12, Jan De Luyck wrote:
> > > Patch applied, kernel built, laptop_mode activated, but my disk just
> > > doesn't want to spin down...
> >
> > [...]
> >
> > > 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?
> >
> > 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.
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.
--
Jens Axboe
On Mon, 12 Jan 2004 05:50:34 MST, Dax Kelson said:
> On Mon, 2004-01-12 at 02:59, Bart Samwel wrote:
> > Jan De Luyck wrote:
> > > 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, b
ut
> > > 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?
>
> On my Dell Inspiron 4150 it is called AC not ACAD.
Dell Latitude C840 calls it /proc/acpi/ac_adapter/AC/state as well.
Bart Samwel <[email protected]> schrieb am 12.01.04 14:47:20:
>
> Jan De Luyck wrote:
> >>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?
I'm currently trying kernel 2.6.1-mm1 with laptop-mode on a reiserfs partition.
If I kill all daemons running on the system and do nothing with it, I can achieve the 10 minutes spin down time I had expected from laptop-mode. However as soon as I start up X with KDE I get regular spin ups every 30 seconds. Looking at the output of "echo 1 > /proc/sys/vm/block_dump", I see an entry every 30 seconds of "kdeinit(15145): WRITE block 65680 on hda1" followed by a whole load of "reiserfs/0(12): dirtied page" and "reisers/0(12): WRITE block XXXXX on hda1".
Due to the regular 30 second interval writes of kdeinit: kded to block 65680, laptop-mode is not particularly usable on this system.
Is this a problem with reiserfs or with kde and is there any fix available?
>
> -- Bart
Kai
______________________________________________________________________________
Erdbeben im Iran: Zehntausende Kinder brauchen Hilfe. UNICEF hilft den
Kindern - helfen Sie mit! https://www.unicef.de/spe/spe_03.php
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:)
--
Cioby
Kai Krueger wrote:
> I'm currently trying kernel 2.6.1-mm1 with laptop-mode on a reiserfs partition.
> If I kill all daemons running on the system and do nothing with it, I can achieve the 10 minutes spin down time I had expected from laptop-mode. However as soon as I start up X with KDE I get regular spin ups every 30 seconds. Looking at the output of "echo 1 > /proc/sys/vm/block_dump", I see an entry every 30 seconds of "kdeinit(15145): WRITE block 65680 on hda1" followed by a whole load of "reiserfs/0(12): dirtied page" and "reisers/0(12): WRITE block XXXXX on hda1".
>
> Due to the regular 30 second interval writes of kdeinit: kded to block 65680, laptop-mode is not particularly usable on this system.
> Is this a problem with reiserfs or with kde and is there any fix available?
Can you take a look at the message that Dumitru Ciobarcianu just sent to
the list (about syslog), and check if it's that?
-- Bart
On Mon, 2004-01-12 at 21:31, Bart Samwel wrote:
> Kai Krueger wrote:
> > I'm currently trying kernel 2.6.1-mm1 with laptop-mode on a reiserfs partition.
> > If I kill all daemons running on the system and do nothing with it, I can achieve the 10 minutes spin down time I had expected from laptop-mode. However as soon as I start up X with KDE I get regular spin ups every 30 seconds. Looking at the output of "echo 1 > /proc/sys/vm/block_dump", I see an entry every 30 seconds of "kdeinit(15145): WRITE block 65680 on hda1" followed by a whole load of "reiserfs/0(12): dirtied page" and "reisers/0(12): WRITE block XXXXX on hda1".
> >
> > Due to the regular 30 second interval writes of kdeinit: kded to block 65680, laptop-mode is not particularly usable on this system.
> > Is this a problem with reiserfs or with kde and is there any fix available?
>
> Can you take a look at the message that Dumitru Ciobarcianu just sent to
> the list (about syslog), and check if it's that?
Won't help him if kdeinit is doing fsync() on every friggind write.
syslog has an option to disable that, that's all.
That's what evolution was doing until some friends helped me build an
fsync "NOP" wrapper .
This e-mail is written using "LD_PRELOAD=no-fsync.so evolution", and the
disc does not spin up every time I switch to another folder or just
another e-mail.
(Yeah, I know it's not an good ideea if I care about my e-mail, but I
keep backups... :)
Now I wonder what will happen if I do this system-wide...
hmmm... candy...
--
Cioby - "kids, don't try this at home"
Dumitru Ciobarcianu wrote:
>>>I'm currently trying kernel 2.6.1-mm1 with laptop-mode on a reiserfs partition.
>>>If I kill all daemons running on the system and do nothing with it, I can achieve the 10 minutes spin down time I had expected from laptop-mode. However as soon as I start up X with KDE I get regular spin ups every 30 seconds. Looking at the output of "echo 1 > /proc/sys/vm/block_dump", I see an entry every 30 seconds of "kdeinit(15145): WRITE block 65680 on hda1" followed by a whole load of "reiserfs/0(12): dirtied page" and "reisers/0(12): WRITE block XXXXX on hda1".
>>>
>>>Due to the regular 30 second interval writes of kdeinit: kded to block 65680, laptop-mode is not particularly usable on this system.
>>>Is this a problem with reiserfs or with kde and is there any fix available?
>>
>>Can you take a look at the message that Dumitru Ciobarcianu just sent to
>>the list (about syslog), and check if it's that?
>
> Won't help him if kdeinit is doing fsync() on every friggind write.
> syslog has an option to disable that, that's all.
I would be surprised if "kdeinit: kded" would do that. In fact, I run
KDE, and it doesn't spin up the disk because of that, even though I have
about 15 kdeinit instances running, including one for kded. Of course, I
might be mistaken.
Kai, can you check the following: is the WRITE of kdeinit preceded by
one or more "kdeinit: kded([some pid]): dirtied page" lines? And if they
are, are they coming directly before the WRITE, or 5 seconds before it,
or 30 seconds before it? This distance might give a clue about the
cause. If it's directly before it (within a second), it's likely that
kded calls fsync. If it's about 5 or 30 seconds before it, it might have
to do with some kind of writeback or expiry interval.
-- Bart
Dumitru Ciobarcianu <[email protected]> wrote:
>
> This e-mail is written using "LD_PRELOAD=no-fsync.so evolution", and the
> disc does not spin up every time I switch to another folder or just
> another e-mail.
>
> ...
> Now I wonder what will happen if I do this system-wide...
I think it's a valid thing to do, personally. I had a "personal
laptop-mode" patch ages ago which just disabled fsync, fdatasync and O_SYNC
kernel-wide. Gone.
It's the sort of thing which email purists tend to get emotional about, but
really this is a choice which should be made available to the user if you
want to do this thing properly.
sync() needs to still work. If you have some app which calls sync() all
the time then you lose.
Bart Samwel <[email protected]> schrieb am 12.01.04 22:54:41:
>
> Dumitru Ciobarcianu wrote:
> >>>I'm currently trying kernel 2.6.1-mm1 with laptop-mode on a reiserfs partition.
> >>>If I kill all daemons running on the system and do nothing with it, I can achieve the 10 minutes spin down time I had expected from laptop-mode. However as soon as I start up X with KDE I get regular spin ups every 30 seconds. Looking at the output of "echo 1 > /proc/sys/vm/block_dump", I see an entry every 30 seconds of "kdeinit(15145): WRITE block 65680 on hda1" followed by a whole load of "reiserfs/0(12): dirtied page" and "reisers/0(12): WRITE block XXXXX on hda1".
> >>>
> >>>Due to the regular 30 second interval writes of kdeinit: kded to block 65680, laptop-mode is not particularly usable on this system.
> >>>Is this a problem with reiserfs or with kde and is there any fix available?
> >>
> >>Can you take a look at the message that Dumitru Ciobarcianu just sent to
> >>the list (about syslog), and check if it's that?
> >
> > Won't help him if kdeinit is doing fsync() on every friggind write.
> > syslog has an option to disable that, that's all.
>
> I would be surprised if "kdeinit: kded" would do that. In fact, I run
> KDE, and it doesn't spin up the disk because of that, even though I have
> about 15 kdeinit instances running, including one for kded. Of course, I
> might be mistaken.
>
> Kai, can you check the following: is the WRITE of kdeinit preceded by
> one or more "kdeinit: kded([some pid]): dirtied page" lines? And if they
> are, are they coming directly before the WRITE, or 5 seconds before it,
> or 30 seconds before it? This distance might give a clue about the
> cause. If it's directly before it (within a second), it's likely that
> kded calls fsync. If it's about 5 or 30 seconds before it, it might have
> to do with some kind of writeback or expiry interval.
I can not see any log entries for "kdeinit: [some pid]: dirtied page". There are only the "kdeinit: () WRITE block 65680 on hda1". By the way, it is always block 65680; also across reboots if that is any indication and I have seen other processes like artsd write to that block without dirtying pages before as well.
Is there a way to find out what kdeinit writes to disk?
the sysklog daemon was shut down during the time of testing, so that shouldn't have effected it.
Thanks for the help,
Kai
> -- Bart
> -
> 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/
______________________________________________________________________________
Nachrichten, Musik und Spiele schnell und einfach per Quickstart im
WEB.DE Screensaver - Gratis downloaden: http://screensaver.web.de/?mc=021110
On Monday 12 January 2004 15:02, Jens Axboe wrote:
> 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.
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
--
I love you, not only for what you are, but for what I am when I am with you.
-- Roy Croft
On Tue, Jan 13 2004, Jan De Luyck wrote:
> On Monday 12 January 2004 15:02, Jens Axboe wrote:
> > 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.
>
> 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?
--
Jens Axboe
Kai Krueger wrote:
> I can not see any log entries for "kdeinit: [some pid]: dirtied page". There are only the "kdeinit: () WRITE block 65680 on hda1". By the way, it is always block 65680; also across reboots if that is any indication and I have seen other processes like artsd write to that block without dirtying pages before as well.
> Is there a way to find out what kdeinit writes to disk?
Ehm... I don't know how to go from a block to a filename on reiserfs.
Jens, do you have an idea?
Anyway, the other possibility is to use other file activity monitoring
tools. Some fam client maybe (couldn't find any so quickly); maybe
Filemon (http://www.sysinternals.com/linux/utilities/filemon.shtml) will
work, but I don't know if it works for Linux 2.6. You may also try "lsof
| grep kded", and see if it's one of those files. For me, it gives:
# lsof |grep kded
kdeinit 1185 bsamwel mem REG 3,65 117196 5146489
/usr/lib/kded.so
kdeinit 1185 bsamwel mem REG 3,65 111412 9470211
/usr/lib/kde3/kded_mountwatcher.so
kdeinit 1185 bsamwel mem REG 3,65 62408 9470683
/usr/lib/kde3/kded_kinetd.so
Alternatively, you can try to attach an strace for kdeinit: kded, and
see what calls it makes, e.g. "strace -p <pid>" or something like that.
-- Bart
Jens Axboe wrote:
>>>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.
>>
>>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
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)
--
Hu Gang / Steve
RLU# : 204016 [1999] (Registered Linux user)
GPG Public Key: http://soulinfo.com/~hugang/HuGang.asc
On Tuesday 13 January 2004 15:21, Hugang wrote:
> 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.
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.
> /dev/hda13 on / 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
--
The executioner is, I hear, very expert, and my neck is very slender.
-- Anne Boleyn