GNOME Bugzilla – Bug 348748
nautilus wakes up about 10 times a second
Last modified: 2006-07-28 00:46:38 UTC
seriously. some very frequent timers have been registered by gnome-vfs. it's inotify-related. poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=24, events=POLLIN}, {fd=14, events=POLLIN}], 6, 87) = 0 gettimeofday({1153902336, 760283}, NULL) = 0 SYS_292(0xe, 0xb4e158d0, 0x1002fc6, 0x821c4a8, 0xb4e158d0) = -1 ENOENT (No such file or directory) SYS_292(0xe, 0x81f4a98, 0x1002fc6, 0x8244c70, 0x81f4a98) = -1 ENOENT (No such file or directory) SYS_292(0xe, 0x81f49d8, 0x1002fc6, 0x8244c70, 0x81f49d8) = -1 ENOENT (No such file or directory) ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1153902336, 760604}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=24, events=POLLIN}, {fd=14, events=POLLIN}], 6, 32) = 0 gettimeofday({1153902336, 800535}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1153902336, 800843}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=24, events=POLLIN}, {fd=14, events=POLLIN}], 6, 124) = 0 ...repeat... having nautilus do a storm of syscalls 10+ times a second is _terrible_ for battery life on laptops. when idle, it should be idle. please fix this bug. btw -- "linus won't let inotify be good" is not a fix for this bug. :)
btw: epiphany also suffers this crazy storm. probably some other apps too. so it's not just nautilus waking up 10 times a second. if we have 10 apps doing monitoring that's 100 wakeups per second. insanity!
This is already partially fixed in CVS. The timers are disabled when they can be. But the missing list timer will almost always be firing because some app will have some rare configuration file on it's watch list. In CVS the missing list is scanned every two seconds. We could up that to every 4 seconds without anyone noticing. The other timer is only active when inotify is waiting for a matching MOVED_TO. gnome 2.14 has more frequent timer beats and doesn't disable the timers when they are not needed.
An indirect way of helping this problem is to look at what files are on an apps missing list, I have a feeling a lot of them are rare configuration files or legacy directories. Maybe some of the cruft could be scrapped off. Anyways, I will post a patch that plays with the timer numbers soon.
Created attachment 69668 [details] [review] gnome-vfs-inotify-timers-tweak-1
The SECOND patch does the following 1) Tweaks some timer numbers in the kernel glue code 2) short circuits the move event matching because we don't deliver move events right now anyways. 3) Ups the missing list scan to once every four seconds
Created attachment 69669 [details] [review] gnome-vfs-inotify-timers-tweak-2
I was actually sort of thinking that when apps are idle they should be idle. Again, imagine a desktop with 10 processes doing file monitoring (not too hard to imagine). Once every 4 seconds is still about twice a second. I was talking to mjg59 today. Circa 2.6.19 a new kernel feature is going to land where the 'HZ' timer will be disabled. The kernel will use its new high-granularity timers to wake up only when it needs to (either because userspace or a driver has scheduled some event). In general, this means that if we make idle apps actually idle then the entire processor can go to sleep for seconds at a time (only to be woken up by IRQs or long-term events like the clock applet waking up once per minute). Is it really too much harder to just watch the parent directory for the file to be created instead of polling?
Maintaining a tree of watched directories and using that to replace the missing list is a possibility. But as we've discussed many times, there are trade offs with that approach. There is a very early patch in #331087 that does some of the work needed to accomplish this. The missing list should never cause a drive to spin up, so the power usage can't be very significant and having a desktop machine that doesn't use a bit of cpu every 4 seconds seems pretty far off right now. Actually getting a list of what's on each desktop apps missing lists would be REALLY interesting. I can't imagine a good reason for an app to have a file on it's missing list for a long period of time.
So, I went and added some code to the inotify backend to dump the missing list every 20 seconds if GNOME_VFS_INOTIFY_DIAG is set. Using this data I have found that every app running on my desktop has an empty missing list. So this bug was already fixed in CVS long before it was filed (CVS has had code to disable all inotify related timers when possible for a while). On my system these processes are using gnome-vfs-monitoring: gnome-settings-daemon gnome-panel nautilus gnome-vfs-daemon Anyways, I will be committing some code tonight that disables the other inotify related timer completely and makes the missing timer fire much less often when it is running at all.