Hi Daniel, That's true, I wasn't very specific, the main aim of my mail was to know if it was a problem at my end, or if it was a problem that was observed by many others. Actually, after I posted this mail, I decided to kill gam_server, like in the good old days, to see what it does. Well, this seemingly fixed the problem for a bit. Now that I look closer, gam_server seems to be using the CPU by growing waves, so to speak. It's peaking at 10% now, I'll see if peaks keep going up. My system has been up for 4 days now without a reboot, so, if my observation is confirmed, it could very well explain how it ended up peaking at 100% after 4 days. >From my perspective, I do not see how resource changes could lead to such a behavior (growing peaks over time), but then again, I could be completely off, hence my poll for other's input on that. I can also not understand how killing the service would fix that 'problem' if it is only related to resources changes (which rate was presumably unchanged by the murder of that poor gam_server). But then again, this may very well be due to my own ignorance. I'll keep watching what gam_server does anyway :-) Le Mardi 3 Mai 2005 14:19, Daniel Veillard a écrit : > On Tue, May 03, 2005 at 01:30:24PM +0200, Sylvain Rouillard wrote: > > Am I the only one to see this? > > > > I've had the problem with gam_server eating 100% of my CPU with FC3, and > > it looks like the problem is back now in FC4T2. I cannot tell since when > > though. But very often (several times per minute I'd say), I see my CPU > > usage going up to 100%, due to gam_server, staying up there for a few > > seconds and going back to normal. > > sounds potentially normal. One of the program asked to watch a > resource which is constantly changing. After a while gam_server detects the > flood of event and switch back to polling. Don't ask for kernel monitoring > of resources which change constantly, the kernel will just by default send > you a continuous stream of change notification events. If it's a different > scenario, then nothing in your mail allowed to guess what it might be. > > Daniel > > -- > Daniel Veillard | Red Hat Desktop team http://redhat.com/ > veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/