Very interesting, File Event Notification is implemented using event ports, which would be the port_getn() and port_associate() calls.
Thanks, Darren. On 22/06/2009 13:36, Juergen Keil wrote: > Hi > > I've filed 6853286 for this. It doesn't contain a stack backtrace, > but it does contain a truss for the gnome application. The > truss shows hundreds of port_getn() event notifications > received (several batches of 64 events). This is followed by > lots of stat() checks for monitored files, followed by > port_associate() calls. > > There also is a dtrace script and dtrace script output included > that should show that file time attributes have changed in > the sub-microsecond part, and this should result in the > file event notification events. > > > > Btw. I also had the problem with the flashing start menu. > It's the same root cause. gnome panel is receiving lots of > file attribute change notifications and is rescanning and > rebuilding the menu entries over and over again. > > > 2009/6/22 Darren Kenny <Darren.Kenny at sun.com>: >> Hi Rod / J?rgen, >> >> Looks like you are both seeing the same issue here... >> >> On 20/06/2009 09:30, J?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. >>> >> >> That's good to know... >> >>> >>> I suspect that gnome is detecting bogus file system changes and is >>> re-scanning start menu >>> entries, folder contents, local setting files, etc. >> >> Yes, that is likely to be the case. >> >>> >>> Can anyone else reproduce this? Is this a known problem? >>> >> >> I'm afraid I've not seen it, but we are using the GAMIN, to monitor file >> changes, and this is using the File Event Mechanism in solaris which is >> similar >> to inotify on Linux - so from what you're seeing it would seem that events >> are >> being fired at that level first. which then triggers GAMIN, and then the >> GNOME >> apps to react. >> >> It would probably be very useful to get some stack traces from the offending >> processes to see if this can confirm where it's all happening. Also, take a >> look >> at the gam_server process which is the one monitoring using FEN and >> dispatching >> events over D-Bus. >> >> Darren. >> >> >> >> >> ---------- Weitergeleitete Nachricht ---------- >> From: Rod Evans <Rod.Evans at Sun.COM> >> To: desktop-discuss at opensolaris.org >> Date: Fri, 19 Jun 2009 14:12:00 -0700 >> Subject: [desktop-discuss] gnome-setting >> For some reason, starting some time last night, this process has been >> going nuts on my desktop, taking significant cpu cycles: >> >> 2551 rie 84M 20M cpu1 40 0 0:02:23 25% gnome-settings-/2 >> >> I kill it and it restarts pretty much the same. >> >> In concert I have nautilus going nuts too: >> >> 2560 rie 212M 89M cpu2 59 0 0:01:23 13% nautilus/5 >> >> and this is thrashing my home directory server with stat's of my home >> directory. >> >> I've tried pulling up my application control panel - where you start >> FireFox/Thunderbird etc. but this just keeps flashing and won't let me >> select anything, or drill down to a sub-menu. >> >> I even tried removing .gnome .gnome2 .gconf .gconfd .metacity. >> >> I have truss output of gnome-settings and nautilus if anyone is interested, >> but my primary desire is to get these processes to go to sleep. >> >> Any advise? >> >> -- >> >> Rod. >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss at opensolaris.org >> >>
