|
Bugzilla – Full Text Bug Listing |
| Summary: | gam_server CPU chew ... | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Meeks <mmeeks> |
| Component: | GNOME | Assignee: | Robert Love <rml> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P5 - None | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
I spent some time investigating this. The view is not pretty. Essentially, gamin is full of timers and it wakes up numerous times a second for numerous reasons--the worst offender being a 33ms wake up. I alleviated the problem by increasing many of the timer intervals and making other timers opportunistic, only running when there is work to do. Gamin now wakes up only a couple of times per second. This is a magnitude improvement. It won't get any better without a hefty gamin rewrite. In talking to jpr, we have decided to check my fixes into Code10 but not issue an update for 10.0. Nice - thanks :-) |
Why does the gam_server have a busy-loop ? Quite often, when it does it's work in the right timeslice one can see it contributing to wasting ones battery in 'top': poll([{fd=1, events=0}, {fd=2, events=POLLIN}, {fd=1, events=POLLIN}, {fd=5, events=POLLIN}, {fd=0, events=POLLIN}, {fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 7, 32) = 0 gettimeofday({1129537823, 955287}, NULL) = 0 gettimeofday({1129537823, 955492}, NULL) = 0 <repeat poll no further sys-calls> why a 32ms timeout ? surely it serves no useful purpose (given the lack of sys-calls) to do this ? surely a well behaved app should sit in 'poll' waiting for event notifications without waking up 30 times a second to do (unnecessary?) work ?