[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 |