Re: [Xen-devel] [PATCH 1/2] cpufreq, powernow: enable/disable core performance boost for all cpus in policy

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.06.13 at 17:32, Jacob Shin <jacob.shin@xxxxxxx> wrote:
> On Thu, Jun 20, 2013 at 08:54:00AM +0100, Jan Beulich wrote:
>> >>> On 20.06.13 at 01:07, Jacob Shin <jacob.shin@xxxxxxx> wrote:
>> > On Wed, Jun 19, 2013 at 03:14:46PM -0500, Jacob Shin wrote:
>> >> Currently, enable/disable turbo mode on AMD is broken:
>> >> 
>> >> $ xenpm enable-turbo-mode 0 <-- works and proper CPU MSR bit is set
>> >> $ xenpm enable-turbo-mode 1 <-- silently broken, MSR bit not set
>> >> 
>> >> Since ->turbo is per policy, when user requests to enable/disable
>> >> turbo mode, we need to set the bit in all of the ->cpus that this
>> >> policy affects.
>> > 
>> > Sorry, I'll have to re-do this [PATCH 1/2], as it does not solve the
>> > problem on platforms with a separate policy per CPU.
>> 
>> But isn't a separate policy per CPU meaning that indeed you want
>> to only fiddle with the one CPU that the policy is getting changed
>> for?
> 
> Yes, this is okay if the end user realizes that on current AMD parts,
> disabling turbo on one core means that it affects all other sibling
> cores that are on the same node.
> 
> $ xenpm disable-turbo-mode 0 </-- hardware bit gets set on CPU0
> $ xenpm get-cpufreq-para
> ...
> CPU0
> turbo mode: disabled
> ...
> CPU1
> turbo mode: enabled
> 
> But since CPU0 and CPU1 are in the same Node, in reality CPU1 also in
> affect has turbo mode disabled.
> 
> If this is okay, then I think the above patch will be fine.

No, this is not okay, but it is also not okay to reflect such a setup
with a per-core policy. Of course things are going to become
difficult if frequency selection can be per-core, but turbo mode
enabling requires that all cores have it enabled in order for it to
actually be used.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel