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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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. :-)

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.

 -- Keir



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