Hi Jurgen, Does the kernel changes cause the /etc/mnttab to be updated in its time stamp?
Could that be, http://monaco.sfbay.sun.com/detail.jsf?cr=2174138 more details here http://bugzilla.gnome.org/show_bug.cgi?id=585360 exacerbated by the kernel change? -Ghee Ju"rgen Keil wrote: > I'm not 100% sure what exactly is broken, but since a day or two (after I > bfu'ed my system > from current onnv-gate sources), the idle gnome desktop has started to > consume *lots* of > cpu time. The system is a SX:CE snv_111, bfu'ed with current onnv-gate bits. > I've never noticed such a problem with bfu of older onnv-gate bits (onnv > before 2009-6-16). > > I see several gnome processes (gnome-settings-daemon, nautilus, gnome-panel) > each trying > to consume 100% cpu time; the processes perform stat system calls all over > the place > (e.g. in /etc/xdg/, my home directory, ~/.local/, ...), and they are reading > /etc/mnttab > quite often. > > > Looking through the change log for the last 2-3 days I noticed the putback > for bug 6539657 > "touch(1) does not set the nanosecond timestamp of a file correctly". > > > When I disable the stat microsecond workaround[*] that was added to the > kernel with the > putback for 6539657, the gnome desktop returns to sane behaviour; the idle > gnome desktop > does not consume lots of cpu time any more. > > > I suspect that gnome is detecting bogus file system changes and is > re-scanning start menu > entries, folder contents, local setting files, etc. > > Can anyone else reproduce this? Is this a known problem? > > > > [*] echo stat_force_usec_granularity/W0 | mdb -wk >
