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

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

On 12/06/2012 10:41 AM, David C Niemi wrote:
> On 12/06/12 13:25, Dirk Brandewie wrote:
>>
>> 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.
> I think being that intimate between the scheduler and the driver is probably not worth the considerable complexity it would introduce.
>
> One bit of general user input I can see being relevant is whether to even consider using
>power-expensive modes like turbo frequencies at all.  In the first 2 or 3 of Arjan's settings,
>yes, you would.  In the last two you would never use them.  If you were optimizing for
 >multithreaded performance you might also not want to use them, but perhaps the 
CPU would be
> happy to handle that decision for you, as Arjan suggests, so it may not be worth trying to
> control it top-down.

Yep there are a bunch of ways to skin the cat when it comes to trading peak
performance for saving power.  The driver code is setup allow for having
multiple sets of tuning parameters that could be selected by the
user/system admin/integrator.

The current driver is tuned to have the same or better peak performance
than the ondemand governor while having better power efficiency.

The performance and power efficiency gains depends on the type of workload.

The thorny question in my mind if people agree that having a per architecture p 
state driver is a valid approach is how should the per architecture drivers
be integrated into a system that allows distributions to build generic kernels
with reasonable default behaviour.

> ...
>> 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.
> I don't think knowing a precise frequency at a precise time is very critical, but finding something to report would help make users feel the driver is working well.  Having low overhead in collecting the information (like an average speed over a period of time) is more important than its precision or timeliness, as the most common use case is just a GUI feature.
>

Providing an interface to retrieve the current requested (operating)frequency
is trivial. Giving the user a warm fuzzy that things are changing what this
type of utility is good for IMHO not an unreasonable desire.

The real question is does it need to be reported via the cpufreq subsystem and
if not where should this driver and others like it report the 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.
> So if it is not practical to get an average, reporting the frequency stamped on the part
>is better than nothing.  It is boring, but less boring than reporting "0".

What would you use this number for in userspace?  I guess I might not
understand exactly what you are asking for here.

--Dirk
>>
>> --Dirk
> DCN
>