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

[Dirk Brandewie <dirk.brandewie@gmail.com>]

On 12/06/2012 09:30 AM, David C Niemi wrote:
> On 12/06/12 11:27, Arjan van de Ven wrote:
>> ...
>>> The exposed configuration interface might be as simple as choosing one of several discrete settings:
>>> - max single-threaded performance
>>> - max multi-threaded performance
>>
>>
>> these are identical on todays silicon btw; or rather, this is not a P state choice item, but a task scheduler policy item.
>
> Here's where there is a difference in power management: if you want to maximize single-thread performance,
 > you're willing to enable power-expensive boost modes on behalf of a thread. 
You don't want to do that for
 > multithreaded performance because your thermal envelope may not let you boost 
them all at once.  Or at
 > least that is what I was thinking.
>

Without being VERY intimate with scheduler it is not clear how you could get
here. How can the governor know which core should get the most performance?

When we request a frequency greater than the frequency stamped on the part
(turbo frequency) the processor opportunistically run at a higher frequency
upto the requested frequency.

> Also some people will be all about I/O throughput, and others will care more about latency than anything else,
 > and percentages for those people may be wildly different than for general 
computation.  So we can't guarantee
 > any particular percentage outside some well-defined benchmarks.  But we could 
try to lump them all together
 > as best we can and have a couple of knobs on the side like the current
 > "io_is_busy", perhaps

io_is_busy is a hint for ondemand to not move to the "idle frequency" while an
I/O is outstanding.   It is not useful if you are not actively managing the 
frequency at idle.


> On reporting frequency: would it be practical to report some sort of medium-term
> average frequency, or if that is not available,

Keeping an average over time is clearly possible in the driver but it is not 
clear how it would be useful.  In most situations other that proving that the
frequency changes over time there is little useful information provided
by knowing the current operating frequency.


 > to just report the max freq that the hardware thread is currently
> eligible to use?
>

In Sandybridge you can request any turbo frequency at any time, what frequency
you actually get is up to the hardware and you can't tell what frequency you 
actually got.  AFAIK there is no way to tell what you are going to get
when you request a frequency higher than the frequency stamped on the part.

--Dirk