GNOME Bugzilla – Bug 514434
Writes to disk every 40s
Last modified: 2009-04-23 02:14:14 UTC
iotop shows that tomboy writes to disk every 10sec. That's bad for power consumption.
Def something to address ASAP. Milestoning to 9.x release
Setting the default assignee and QA Contact to "tomboy-maint@gnome.bugs".
I can confirm this - iotop shows the same thing on my notebook. tomboy: 0.10.2-0ubuntu1 mono: 1.2.6+dfsg-6ubuntu3
From Launchpad ( https://launchpad.net/bugs/222907 ) people are reporting both 10 seconds and 40 seconds. From the original reporter in LP (which was taken in April of 2008): ------ Some diagnosis shows that the files affected are in ~.wapi, and that those files are being used by Tomboy. $ while true; do find . -mmin -1 -type f -print0 | xargs -0 ls --full-time -ltr; echo; sleep 1; done -rw------- 1 mukesh mukesh 252905 2008-04-26 22:06:54.000000000 -0700 ./.mozilla/firefox/gudrke3v.default/sessionstore.js -rw------- 1 mukesh mukesh 3686404 2008-04-26 22:07:31.000000000 -0700 ./.wapi/shared_fileshare-qube-Linux-i686-36-11-0 -rw------- 1 mukesh mukesh 1277960 2008-04-26 22:07:31.000000000 -0700 ./.wapi/shared_data-qube-Linux-i686-312-11-0 [9 seconds of output clipped] -rw------- 1 mukesh mukesh 252905 2008-04-26 22:06:54.000000000 -0700 ./.mozilla/firefox/gudrke3v.default/sessionstore.js -rw------- 1 mukesh mukesh 3686404 2008-04-26 22:07:41.000000000 -0700 ./.wapi/shared_fileshare-qube-Linux-i686-36-11-0 -rw------- 1 mukesh mukesh 1277960 2008-04-26 22:07:41.000000000 -0700 ./.wapi/shared_data-qube-Linux-i686-312-11-0 [9 seconds of output clipped] -rw------- 1 mukesh mukesh 252905 2008-04-26 22:06:54.000000000 -0700 ./.mozilla/firefox/gudrke3v.default/sessionstore.js -rw------- 1 mukesh mukesh 3686404 2008-04-26 22:07:51.000000000 -0700 ./.wapi/shared_fileshare-qube-Linux-i686-36-11-0 -rw------- 1 mukesh mukesh 1277960 2008-04-26 22:07:51.000000000 -0700 ./.wapi/shared_data-qube-Linux-i686-312-11-0 $ lsof -n | grep wapi tomboy 12832 mukesh mem REG 8,3 3686404 1737315 /home/mukesh/.wapi/shared_fileshare-qube-Linux-i686-36-11-0 tomboy 12832 mukesh mem REG 8,3 1277960 1736941 /home/mukesh/.wapi/shared_data-qube-Linux-i686-312-11-0 ------ Also the latest comments says: "Confirmed on Intrepid Alpha 6 with tomboy 0.11.3-0ubuntu1, and on a fully-updated install with tomboy 0.12.0-0ubuntu1. The update interval appears to be forty seconds."
With 0.10.2 (debian/sid) i don't see this behaviour anymore. Tomboy only wakes up every 10s [pid 5989] 0.000091 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000840 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000104 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000154 waitpid(5987, 0x48aa7a9c, WNOHANG) = -1 ECHILD (No child processes) [pid 5989] 0.016258 nanosleep({10, 0}, NULL) = 0 [pid 5989] 10.000248 time(NULL) = 1222464325 [pid 5989] 0.000083 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000091 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000882 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000106 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000153 waitpid(5987, 0x48aa7a9c, WNOHANG) = -1 ECHILD (No child processes) [pid 5989] 0.000273 nanosleep({10, 0}, NULL) = 0 [pid 5989] 10.000232 time(NULL) = 1222464335 [pid 5989] 0.000082 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000093 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000945 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000112 semop(0x40008, 0x1, 0, 0x48aa7af8) = 0 [pid 5989] 0.000155 waitpid(5987, 0x48aa7a9c, WNOHANG) = -1 ECHILD (No child processes) [pid 5989] 0.000275 nanosleep({10, 0}, NULL) = 0 [pid 5989] 10.000228 time(NULL) = 1222464345
Benoît, did you see something in the systrace -f output when you could reproduce the problem? Are writes not happening on your setup? I don't know exactly what's doing it, but writes are occurring regularly, meaning that I/O is happening even when the machine is idle. It doesn't happen when Tomboy is shut down. Is there a better way for me to trace this so that you can see what I mean? If you run "watch 'find ~/.wapi -mmin -1 -type f -print0 | xargs -0 ls --full-time -ltr'", you'll see it happening with the current version.
Additionally, if you use iotop, you can see that writes being performed by the Tomboy process. (It's easier to see with "iotop -d 10 -u `whoami`", so that it doesn't disappear right after it performs its write.)
It's already a strace -f, a bit weird since the child 5989 waits for it's parent 5987 ... no write at all, from time to time, i can see some poll waking up and then doing little chat on a unix socket. But indeed, these wapi files are mapped : 48566000 1252K rw-s- /home/benoit/.wapi/shared_data-ibook-Linux-ppc-312-11-0 4869f000 4004K rw-s- /home/benoit/.wapi/shared_fileshare-ibook-Linux-ppc-40-11-0 and are update every ~40s. So Greg is right, the problem is different from what i saw from the start (write(2)). (Increasing that 10s interval would anyway save some power)
Is this only happening with Tomboy, or does it happen with other Mono apps?
Indeed: Mono JIT compiler version 1.9.1 (tarball) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: normal Notifications: epoll Architecture: ppc Disabled: none + public class Sleep { public static void Main() { System.Threading.Thread.Sleep(3600000); } } = ~/.wapi/shared_* files are updated every 40s.
I think it might be related to this : http://www.mono-project.com/Article:IOChanges#Keeping_State
(In reply to comment #11) > I think it might be related to this : > http://www.mono-project.com/Article:IOChanges#Keeping_State Agreed...please file in Mono bugzilla. Marking NOTGNOME.
https://bugzilla.novell.com/show_bug.cgi?id=434566
What about experimenting that workaround https://bugzilla.novell.com/show_bug.cgi?id=434566#c2 ?
(In reply to comment #14) > What about experimenting that workaround > https://bugzilla.novell.com/show_bug.cgi?id=434566#c2 ? Good point. Re-opening.
Setting MONO_DISABLE_SHM means that some things like cross-process mutexes/ semaphores will not work. If tomboy doesn't use those things (likely), then it will work fine, and won't write to the disk every 40s (I tested this).
The underlying problem is now fixed in mono SVN by using Posix shared memory instead of a file for IPC.
Awesome, thanks Zoltan! Need to look at MONO_DISABLE_SHM and make sure it doesn't cause any problems with dbus, etc.
Okay, committed this fix in r2345. Works fine for me in openSUSE. If anybody has troubles please let me know!