|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/9] Porting the intel_pstate driver to Xen
>>> On 24.04.15 at 17:42, <wei.w.wang@xxxxxxxxx> wrote:
> On 24/04/2015 23:04, Jan Beulich wrote
>> >>> On 24.04.15 at 16:56, <wei.w.wang@xxxxxxxxx> wrote:
>> > On 24/04/2015 20:57, Jan Beulich wrote
>> >> I'm not sure how else to express what I want (no matter how many
>> >> internal governors the intel_pstate driver has).
>> >>
>> >> xenpm set-scaling-governor powersave
>> >> xenpm set-scaling-governor ondemand
>> >> xenpm set-scaling-governor performance
>> >>
>> >> each should switch the system into a respective state, no matter
>> >> whether internally to the driver this means a change of governors or
>> >> just a modification to {min,max}_pct.
>> >>
>> >> And obtaining the current state after any of the above should show
>> >> the same governor in use that was set (and not "internal"), again no
>> >> matter how this is being achieved internally to the driver.
>> >
>> > Thanks Jan, that's clear. But this will have another issue. For
>> > example, we set-scaling-governor to "ondemand", then we adjust
>> > min_pct=max_pct = 60%. The timer function may generate results like
>> > 35%, 55%, 45%..., but the CPU just keeps running with 60%.
>>
>> So I must be misunderstanding something then: How can the driver do
>> anything at all when told to run the system at 60%?
>
> The {min,max}_pct is a limit.
That's clear. The question is whether these are hardware imposed limits
or set by the user. In the latter case ...
>> > Then, this is not "ondemand" at all (I think this should be another
>> > reason why the intel_pstate driver does not call its governor
>> > "ondemand").
>> >
>> > The intel_pstate driver in the kernel has already got rid of the old
>> > governor convention. They let the user get what they want through
>> > simply adjusting the {min,max}_pct (the {min,max}_pct actually limits
>> > how the performance is selected).
>>
>> Adjusting the values individually to me very much looks like the userspace
>> governor.
>
> Yeah, that example was like "userspace". Please take a look at this example:
> [min_pct=60%, max_pct=80%], the timer generates 45%, 55%, 65%, 70%, 75%, 90%,
> then the final target values will not be constant.
(the 45%, 55%, and 90% here shouldn't happen in any case)
> The ones (65%, 70%, 75%)
> falling into the limit interval behaves like "ondemand", others are not.
... restricting to these would be the job of the driver, and
- ondemand would be 0...100
- powersave would be 0
- performance would be 100
Everything else would be userspace.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |