Laptop-mode v7 for linux 2.6.1
Bart Samwel <[email protected]> schrieb am 12.01.04 22:54:41:
Quoted 19 lines
Quoted 11 lines · Dumitru Ciobarcianu
Quoted 8 lines
Quoted 5 lines
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.
Quoted 7 lines
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
Quoted 6 lines
-- 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
Quoted 2 lines · Kai Krueger
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