Re: [PATCH RFC 0/1] cpufreq/x86: Add P-state driver for sandy bridge.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/6/2012 12:45 PM, Rafael J. Wysocki wrote:

My idea for a policy "dial" is mostly

* Uncompromised performance
* Balanced - biased towards performance     (say, defined to be lowest power at most a 2 1/2% perf hit)
* Balanced                                  (say, at most a 5% perf hit)
* Balanced - biased towards lower power     (sat, at most a 10% perf hit)
* Uncompromised lowest power

we can argue about the exact %ages, but the idea is to give at least some reasonably definition that people can understand,
but that also can be measured

It looks like you'd like a tunable setting the maximum allowed performance hit
due to power management.  Is that correct?

basically yes, but not as a continuous dial (that's not practical), but as a
certain number of sensible steps.... I'm not sure it makes sense to have more than 5 steps.

My key interest is to have something that is both understandable by the sysadmin as to what it means,
but also something that you can actually measure (and thus test)...
while still describing a desire/preference, not a specific implementation of an algorithm.

A sysadmin understands "willing to give up at most 5% of max performance to save power"... and he can reason about it,
and think about it, take his own situation into account and then make a decision on it as a result.

The policy side can then measure algorithms and tunables to make sure they stay within that 5%
(of course on "reasonable" or "realistic" workloads.. not theoretical foofoo stuff).

You must put something like this in place, because if you just call it "balanced", that means 101 different things
to 100 people.... and as a result neither the algorithm side can ever do anything (SOMEONE somewhere will regress),
nor can the sysadmin side make a reasonable decision, since it means something else on each machine as well.




--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux