Version: (using KDE KDE 3.5.6) Installed from: Debian testing/unstable Packages Reported in Debian BTS at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364119 (not sure if assigned to the right application.) I got a report from a laptop-mode-tools user saying that kwin kept his disk spun up. I checked his logs, and indeed it seems to be the case that his kwin process explicitly syncs pretty regularly. I straced my own kwin to confirm this behaviour, and I see the following: open("/home/bsamwel/.kde/share/config/kwinrulesrc6EREMa.new", O_RDWR|O_CREAT|O_EXCL, 0600) = 11 umask(0) = 022 umask(022) = 0 fchmod(11, 0600) = 0 getgid32() = 1000 getuid32() = 1000 fchown32(11, 1000, 1000) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 stat64("/home/bsamwel/.kde/share/config/kwinrulesrc", {st_mode=S_IFREG|0600, st_size=824, ...}) = 0 getuid32() = 1000 getgid32() = 1000 fchmod(11, 0100600) = 0 fchmod(11, 0600) = 0 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fstat64(11, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6705000 _llseek(11, 0, [0], SEEK_CUR) = 0 write(11, "[1]\ndescription=(Default) Disabl"..., 824) = 824 fdatasync(11) = 0 close(11) = 0 munmap(0xb6705000, 4096) = 0 rename("/home/bsamwel/.kde/share/config/kwinrulesrc6EREMa.new", "/home/bsamwel/.kde/share/config/kwinrulesrc") = 0 and then: open("/home/bsamwel/.kde/share/config/kdeglobalsZbum9a.new", O_RDWR|O_CREAT|O_EXCL, 0600) = 11 umask(0) = 022 umask(022) = 0 fchmod(11, 0600) = 0 getgid32() = 1000 getuid32() = 1000 fchown32(11, 1000, 1000) = 0 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0 stat64("/home/bsamwel/.kde/share/config/kdeglobals", {st_mode=S_IFREG|0600, st_size=5804, ...}) = 0 getuid32() = 1000 getgid32() = 1000 fchmod(11, 0100600) = 0 fchmod(11, 0600) = 0 fcntl64(11, F_GETFL) = 0x2 (flags O_RDWR) fstat64(11, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6705000 _llseek(11, 0, [0], SEEK_CUR) = 0 write(11, "[$Version]\nupdate_info=kded.upd:"..., 4096) = 4096 write(11, "ndow to Desktop 2=none\nWindow to"..., 1708) = 1708 fdatasync(11) = 0 close(11) = 0 munmap(0xb6705000, 4096) = 0 rename("/home/bsamwel/.kde/share/config/kdeglobalsZbum9a.new", "/home/bsamwel/.kde/share/config/kdeglobals") = 0 So, here's my question: is that call to fdatasync() really necessary? And can it be disabled somehow? It makes laptop mode pretty much unusable on KDE. :-( Basically, the way to reproduce this should be: 1. Install laptop-mode-tools, set ENABLE_LAPTOP_MODE_ON_AC=1 in laptop-mode.conf, and do /etc/init.d/laptop-mode reload. 2. Stop sysklogd. 3. Do "echo 1 > /proc/sys/vm/block_dump" 4. Use kwin without any necessary disk reads, and monitor dmesg. If the bug still exists, you will see that kwin causes WRITE operations more than once every 10 minutes (the default write interval of laptop-mode-tools). I once looked into the code, and I traced the problem to an fsync() or fdatasync() call in one of the file handler functions in the underlying KDE libraries. It was a sync call that was completely unnecessary and uncalled for, I think it was triggered when kwin tried to save its settings or something like that. Another way to reproduce this: run kwin under strace, and check for fsync(), fdatasync() and sync() syscalls. I hope you can fix this (if it still occurs), because it's really annoying for KDE users who use a laptop and who try to save battery power using laptop-mode-tools. Cheers, Bart
This also causes *tremendous* slowdowns on heavily disk-loaded machines. I measured with latencytop fsync() times of >9 seconds on a machine otherwise only used for a few kgets, a `find / >/dev/null' process and kernel compilation. If the fsync() call really is totally unnecessary, fixing this should also boost performance under heavy disk loads.
I have personally contacted the KLaptopDaemon author/assigned and he confirmed that the tool is deprecated in KDE SC 4 (replaced by PowerDevil) and that there are no current efforts to support/maintain the KDE SC 3 version. Because of this, I will close the reports as UNMAINTAINED. Regards