Messages in this thread | | | Date | Mon, 30 Jun 2008 16:31:40 +0200 | From | Andi Kleen <> | Subject | Re: [RFC v1] Tunable sched_mc_power_savings=n |
| |
David Collier-Brown wrote: > Vaidyanathan Srinivasan wrote: >> I am trying to find answer to the question: Should we have the power >> saving tunable as 'nice' value per process or system wide? >> >> How should we interpret the POWER parameter in a datacenter with power >> constraint as mentioned in this thread? Or in a simple case of AC vs >> battery in a laptop. > > I agree with Tim re setting them all independently,
I agree that powernice is likely a good idea (although the semantics are not 100% clear yet), but there's still the issue (shared with ionice) that 99.99+% of all setups won't set powernice explicitely so you still need a reasonable default when it is not set.
Me thinks the correct strategy would be something like this:
- When powernice is set prefer it - For the idle socket optimization: use nice because it's unclear that "race to idle" applies here. - For ondemand: when nice is set behave more like the conservative governor and take longer to crank up [this might be controversal]
Also are the best powernice semantics the same between idle sockets and ondemand? I'm not sure.
and suggest that > they're all really per-process values: setting power saving system-wide > is meaningful, but so are individual settings. > There is therefor an argument for making them subsets of > a higher-level nice program. > > Mind you, the order in which one *implements* the capability, > and whether one does powernice first and adds it to nice later > is your call! I have no idea of how hard what I suggested is (;-))
In general for Linux deployment it tends to be easier to provide another package with an own command instead of patching a core package like coreutils
With an own package you can just tell the user "type (yum|zypper|apt-get|...) install powernice", while an updated coreutils tends to be more trouble or even require a distribution update.
-Andi
| |