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/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.
...
> 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.

>
> > 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".
>
> --Dirk
DCN
--
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