Red Hat Bugzilla – Full Text Bug Listing
|Summary:||gnome-power-manager sets "bogus" ondemand tunables when on AC|
|Product:||[Fedora] Fedora||Reporter:||Arjan van de Ven <arjan>|
|Component:||gnome-power-manager||Assignee:||David Zeuthen <davidz>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||jfeeney, lex.lists, mclasen, rhughes, richard|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-26 02:54:27 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||235704, 309171, 418441|
Description Arjan van de Ven 2007-09-26 01:15:46 EDT
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.
Comment 1 Arjan van de Ven 2007-09-26 01:24:32 EDT
(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)
Comment 2 David Zeuthen 2007-09-26 11:04:36 EDT
Richard, why? Thanks.
Comment 3 Richard Hughes 2007-09-26 14:49:57 EDT
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.
Comment 4 Arjan van de Ven 2007-09-26 15:15:34 EDT
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.
Comment 5 Richard Hughes 2007-09-26 15:32:13 EDT
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.
Comment 6 Arjan van de Ven 2007-09-26 15:41:02 EDT
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.
Comment 7 Arjan van de Ven 2007-09-26 15:44:12 EDT
(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)
Comment 8 Matthias Clasen 2007-09-27 13:50:32 EDT
Should Fedora bugs be on the Intel5.2Features tracker ?
Comment 9 Geoff Gustafson 2007-09-28 15:39:14 EDT
Not really, but it will help me not lose this until we have a RHEL5 issue submitted, if that's okay.
Comment 10 Matthias Clasen 2007-10-04 23:20:07 EDT
Richard, David, which one is it ? gpm bug or hal bug ? and can we fix it ?
Comment 12 Richard Hughes 2007-11-02 14:49:41 EDT
mclasen: it's both. It's a HAL bug because it's setting the wrong tunable, and a gnome-power-manager bug because it probably should just leave the policy to ondemand no matter what the user says. I'm really tempted to rip out the CPU freq stuff from g-p-m trunk.
Comment 13 David Zeuthen 2007-11-02 15:09:27 EDT
Yeah. I'm thinking just disabling the power management stuff from the hal builds too. Should be as simple as configuring the sources using --without-cpufreq. Arjan, would this work for you?
Comment 14 Arjan van de Ven 2007-11-02 15:24:03 EDT
It's basically the right thing; it sounds nice in theory for all to bother with this stuff, in practice it doesn't work well because there really isn't/shouldn't be anything to tune in the first place.
Comment 18 Bug Zapper 2008-05-13 23:16:46 EDT
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Richard Hughes 2008-07-27 06:16:23 EDT
g-p-m doesn't touch any of the cpufreq stuff anymore upstream.
Comment 20 lexual 2009-02-25 23:17:35 EST
Can this be closed now?