Summary: | kded prevents hard disk to sleep on laptop due to periodic fdatasync calls | ||
---|---|---|---|
Product: | [Unmaintained] kdelibs | Reporter: | Casteyde.Christian <casteyde.christian> |
Component: | kded | Assignee: | David Faure <faure> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | l.lunak, me, sami.liedes |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Casteyde.Christian
2007-03-03 16:06:48 UTC
I can confirm similar trouble--kded wakes up my disk every 20-100 seconds when in laptop mode. Example output from lm-profiler: Accesses at 323/600 in run: [ 4279.996000] kded Accesses at 346/600 in run: [ 4304.004000] kded Accesses at 446/600 in run: [ 4410.996000] kded I'd be happy to do a little more testing to find out what is actually being written. I believe this takes about 30 minutes off of my battery life. You need to find out which kded module does this. `dcop kded kded loadedModules` will show you the currently loaded modules. Now try to unload them one by one like this: dcop kded kded unloadModule kmilod until you find which one is responsible for this behavior. Casteyde, Luke: do you have an idea which module causes this? Please follow the steps described by David Faure, otherwise I'm afraid we should close this bug due to insufficient information. It would be finding for a (possibly non-existing) needle in a haystack. No, I didn't have any occasion to do these tests. The last time I got some hard drive spin up problem was with kget, but this was not kded. I seem to have KDE 3.5.9 kded fsync()ing a lot too. I happen to be running multiple instances of kget with fast network connection at the moment too. According to latencytop, this occasionally blocks kded occasionally for as many as 3 to 8(!) seconds during heavy disk activity. This is not a laptop, but I believe things would be a lot faster if programs didn't do unnecessary fsync()s. Actually now that I take a good look, I get fsync() with 6+ seconds of latency in a konqueror process too. The fsync problem is going to be pervasive. Indeed, with the gap between HDD latencies and other components nowadays, fsync seems to be the **real** big problem for both latency and power saving: it'll have to be adressed. For information (and other reasons), I've filled this kernel bug, since ext3 fsync implementation is also stupid: http://bugzilla.kernel.org/show_bug.cgi?id=9546 Basically, it states that both kmail and firefox 3 won't run on linux in the near term, which seems to me critical (but I consider all OS have the same problem). I consider fsync as a denial of service now. Software that uses fsync should really look for another way to ensure data is consistent, trusting the journaling filesystems. fsync should never have existed except for softwares such as databases and user space filesystems. By the way, I did a small .so that implements fsync, sync and fdatasync as nothing and I preloaded it: the problems vanished. See in the comments on kernel bugzilla for source (quite trivial). KDE4 does not use fsync/fdatasync unless $KDE_EXTRA_FSYNC is set, so this should not be a problem anymore. |