Bug 600500 - hamster-applet 2.30.1 generates an unacceptable number of CPU wakeups-from-idle per second
hamster-applet 2.30.1 generates an unacceptable number of CPU wakeups-from-id...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: hamster-applet (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Mads Villadsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-04 16:38 EDT by James Ralston
Modified: 2010-06-06 14:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-06 14:16:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 615338 None None None Never

  None (edit)
Description James Ralston 2010-06-04 16:38:29 EDT
For hamster-applet-2.28.3-0.1.20100215git.fc12 on Fedora 12, hamster-applet generates very few interrupts per second. This is largely because if hamster applet is not active, it sits in a poll() loop that doesn't timeout until the next (clock wall) minute rolls over:

poll([{fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=3, events=POLLIN|POLLPRI}, {fd=5, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=30, events=POLLIN}, {fd=28, events=POLLIN}, {fd=27, events=POLLIN}], 10, 22869

I.e., the timeout value (the third argument) varies between 0 and 60000 milliseconds.

But this behavior changed with hamster-applet-2.30.1-1.fc13 on Fedora 13. Now, hamster-applet always seems to use 11 milliseconds for the poll() timeout. As a result, hamster-applet causes an additional ~180 wakeups-from-idle per second (using powertop to measure both with and without hamster-applet running).

I'm not sure what problem the hamster-applet developers were trying to solve by making this change, but I'm sorry: it is TOTALLY unacceptable to have a non-active, non-focused panel applet generate this phenomenal amount wakeups-from-idle per second. Not only is it a waste of power, but for people using laptops, running hamster-applet could be the difference whether the laptop's batteries make it through the meeting/presentation, or whether the laptop's batteries die before then.

When I take hamster-applet-2.28.3-0.1.20100215git.fc12.src.rpm and rebuild it for Fedora 13, it has the same polling behavior as on Fedora 12; that is, it sleeps between 0 and 60000 milliseconds. Thus, I know that other differences between Fedora 12 and Fedora 13 aren't the source of hamster-applet's unacceptable behavior; something in hamster-applet itself had to change to do this.

In summary, this change is a severe problem that makes hamster-applet
antagonistic to people using laptops or other low-power/battery-powered
devices. It should be addressed ASAP.
Comment 1 James Ralston 2010-06-04 16:42:38 EDT
Note the reference to the bug I filed with upstream (bugzilla.gnome.org). It might be best to address this bug there...
Comment 2 James Ralston 2010-06-04 19:49:10 EDT
Ok, this was fixed upstream already:

http://git.gnome.org/browse/hamster-applet/commit/?id=5dd38415494395436e9ebf80433fcbd199120217

It's a very simple patch. Please backport.
Comment 3 Mads Villadsen 2010-06-06 14:16:28 EDT
The gnome 2.30.2 release is happening in about two weeks, so instead of pushing out multiple updates in a row I will wait for that release.

Thank you for taking the time to report this bug.

Note You need to log in before you can comment on or make changes to this bug.