Bug 354641 - gnome-power-manager sets "bogus" ondemand tunables when on AC
gnome-power-manager sets "bogus" ondemand tunables when on AC
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gnome-power-manager (Show other bugs)
5.1
All Linux
low Severity medium
: ---
: ---
Assigned To: David Zeuthen
desktop-bugs@redhat.com
:
Depends On:
Blocks: 309171
  Show dependency treegraph
 
Reported: 2007-10-26 14:33 EDT by Tim Burke
Modified: 2013-03-05 22:53 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2008-0478
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 13:23:20 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)

  None (edit)
Description Tim Burke 2007-10-26 14:33:14 EDT
+++ This bug was initially created as a clone of Bug #306401 +++

Description of problem:

g-p-m sets the /sys/devices/system/cpu/cpuX/cpufreq/ondemand/up_threshold value
to 31 when on AC. This is not a good value (the default 80 is a LOT better for
any scenario); in fact it is extremely questionable that g-p-m even touches this
value at all!

I would like to request that g-p-m, when on AC, at least uses 80 or higher for
this value; it's also a good question to find out why 31 was used in the first
place... if there was no good reason (or there was a reason that no longer is
valid) I would like to request that g-p-m just leaves this value alone.

-- Additional comment from arjan@linux.intel.com on 2007-09-26 01:24 EST --
(just as background; in principle the ondemand governer will go to max frequency
if the current application is running into a performance boundary at the current
frequency. As such the theoretical value for up_threshold is 100. However to
allow a little bit slack due to measurement errors (until 2.6.23, the cpu usage
was not super accurate), a 20% slack value was used, so up_threshold was set to
80. up_threshold was a debug knob for ondemand developers, and it was never
intended nor imagined to be a user tunable; the value "31" surely makes no
sense, there isn't ever going to be a 69% measurement error, nor does it make
sense to have a different value for AC and DC; the measurement error isn't going
to depend on being on AC or DC unless you have a kernel which has a different
internal tick rate for AC versus DC, and Linux never had that)


-- Additional comment from davidz@redhat.com on 2007-09-26 11:04 EST --
Richard, why? Thanks.

-- Additional comment from richard@hughsie.com on 2007-09-26 14:49 EST --
Well, the consensus at the time was to tweak the performance for battery and ac
states as this would affect the latency. I was told to use 85% for AC and 25%
for battery. g-p-m sets the performance through HAL, so if 85% isn't mapped
correctly, it's probably a hal addon bug. 

-- Additional comment from arjan@linux.intel.com on 2007-09-26 15:15 EST --
ok what ends up happening is not that the performance is tweaked, but that the 
measurement error slack is tweaked.

Note: With ondemand, there really is no need to tweak any performance at all. 
Maybe the hal code should just not do anything.

(With userspace governer.. different story obviously)

In addition; I think it's a fundamental mistake to tune AC-vs-battery, because 
that implies that power consumption is not important for the AC case, which is 
absolutely incorrect (just ask any datacenter sysadmin)....

So.. is this a hal bug because it tunes some random different meaning sysfs 
tunable (heck, since it tries to tune anything at all) or is there a more 
fundamental issue around what to do in general here.


-- Additional comment from richard@hughsie.com on 2007-09-26 15:32 EST --
Sure, I'm with you on the saving power on AC thing. I was told this would affect
latency - i.e. a snappier system on AC than battery. Is this incorrect? This
sounds like a HAL bug, but I'm wondering if g-p-m shouldn't just leave cpufreq
alone completely.

-- Additional comment from arjan@linux.intel.com on 2007-09-26 15:41 EST --
What ends up being set in the end doesn't really impact latency. 
(if one wanted to tweak latency then other values should have been tweaked, 
not this one). Ondemand is very agressive anyway already in ramping speed up 
when needed anyway, realistically it doesn't require any tuning at all.

I agree with the notion that g-p-m should leave cpufreq alone, at least 
normally. I can see a point where a user gets to see a knob that says "get me 
maximum performance no matter what", which would just switch governer (but 
then again, ondemand does a pretty good job of going to full speed when needed 
anyway)... but other than that... ondemand (and any other cpufreq policy) 
should "Just Work" without handholding or tuning.


-- Additional comment from arjan@linux.intel.com on 2007-09-26 15:44 EST --
(at this point, while BZ still says gpm, I'm not clear if it's a hal thing, or 
a gpm thing, or miscommunication between both; since all interested folks are 
on this bug anyway that's no big deal)

-- Additional comment from mclasen@redhat.com on 2007-09-27 13:50 EST --
Should Fedora bugs be on the Intel5.2Features tracker ?

-- Additional comment from grgustaf@redhat.com on 2007-09-28 15:39 EST --
Not really, but it will help me not lose this until we have a RHEL5 issue
submitted, if that's okay.


-- Additional comment from mclasen@redhat.com on 2007-10-04 23:20 EST --
Richard, David, which one is it ? gpm bug or hal bug ? and can we fix it ?
Comment 2 RHEL Product and Program Management 2007-10-26 14:44:44 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 3 David Zeuthen 2007-11-02 12:36:38 EDT
I will look into what is going on here.
Comment 4 Ronald Pacheco 2007-11-06 13:38:02 EST
Arjan,

What priority would you give this?
Comment 5 Arjan van de Ven 2007-11-06 13:40:48 EST
this would be high priority; the effect of the mistuning is actually really 
bad while the fix is rather trivial...
Comment 6 David Zeuthen 2008-01-02 14:50:29 EST
* Wed Jan 02 2008 David Zeuthen <davidz@redhat.com> - 0.5.8.1-30%{?dist}
- Turn off the user space cpufreq stuff; it does more harm than good
- Resolves: #306401

This solution is per comment 13 bug 306401 - see that one for details.
Comment 9 Suzanne Hillman 2008-01-30 13:34:54 EST
I am not really clear on how this got labeled VERIFIED; is this truly VERIFIED
as fixed? If so, by whom?
Comment 10 Suzanne Hillman 2008-02-06 15:41:47 EST
Sorry; missed comment #8.
Comment 12 errata-xmlrpc 2008-05-21 13:23:20 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0478.html

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