Bug 600500 - hamster-applet 2.30.1 generates an unacceptable number of CPU wakeups-from-idle per second
Summary: hamster-applet 2.30.1 generates an unacceptable number of CPU wakeups-from-id...
Alias: None
Product: Fedora
Classification: Fedora
Component: hamster-applet   
(Show other bugs)
Version: 13
Hardware: All Linux
Target Milestone: ---
Assignee: Mads Villadsen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-04 20:38 UTC by James Ralston
Modified: 2010-06-06 18:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-06 18:16:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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

Description James Ralston 2010-06-04 20:38:29 UTC
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 20:42:38 UTC
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 23:49:10 UTC
Ok, this was fixed upstream already:


It's a very simple patch. Please backport.

Comment 3 Mads Villadsen 2010-06-06 18:16:28 UTC
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.