RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年8月31日 18:05
>
>On 31/8/07 02:20, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Yes, that information has to be parsed and notified to Xen. Some PV l
>> ogic needs to be hooked into cpufreq as you said. Userspace program
>> is a good choice too, like the user level ACPI interpreter. However the
>> major block is to parse dynamically changed information. For example,
>> cpufreq info may change (due to some hardware events) and OSPM
>> is required to re-evaluate P-state info. That re-evaluation may get
>> different info after checking some hardware bits. To do it in user level,
>> firstly we need emulate an event and then need virtualize those bits.
>> Not very easy to track. So I more agree with you that an user-level
>> stuff is the way to go, at least for the start.
>
>Not sure what you're saying here. It seems to be 'getting async acpi
>events
>in user space would be hard, so doing this stuff in user space is the way
>to
>go'. The argument and conclusion seem at odds with one another.
>Unfortunately I have to reluctantly agree with the argument: at least, it
>would be some work to provide an interface to allow user processes to
>access
>the ACPI event mechanism. I'm not sure how much. :-)

Oh, my fault here. The argument is as you said that it's a bit hard and 
the conclusion is really that user level 'governor' is more easier. :-P

>
>Personally I'd concentrate on picking out C-state control from ACPI, pass
>that info down to Xen, and hook that into the idle-loop and cpu-hotplug
>paths. Much easier, no async acpi events to worry about, and probably
>as
>good or better power saving where you have more than a couple of
>cores.
>

Agree, and some of my colleagues currently works on that part (More 
specifically, Winston Wang and Ke Yu). But one caveat is that C-state 
is still likely to be changed dynamically due to hardware event, like AC 
power change on mobile or some monitor logic on server. But for the 
first step we can just tweak kernel parser and pass to Xen. They should 
get something experimental out once getting a measurable power 
saving, like:
        * C-state policy in idle loop
        * Tick-less Xen at Idle, to reduce deep C-state interrupted too early
        * TSC/APIC freeze at deeper C-states
Also the cpu-hotplug path like you mentioned here.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel