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

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

>From: Rik van Riel [mailto:riel@xxxxxxxxxx]
>Sent: 2007年8月30日 22:59
>
>Keir Fraser wrote:
>
>> Personally I'm a fan of doing it in dom0 userspace, although doing it
>within
>> Xen can also be argued for. Doing it in dom0 kernel doesn't seem very
>> attractive apart from the obvious pragmatic advantage that all the code
>is
>> already in the Linux kernel. :-)
>
>Code duplication is bad.  It is the reason why Xen
>will (hopefully) go away in the long run.  Please do
>not propagate this horrible idea that all code should
>be copied around and have obsolete versions maintained
>forever.
>
>The dom0 kernel is where the code already lives, so
>that code should be used.
>

My several points on this:

a) We shouldn't eliminate all possibilities in the start, and all experiments 
need to be done to see whether effort is worth for best power saving

b) Code duplication is definitely bad. But if finally xen-based governor is 
proved to be with best power saving cap, why not? Actually it's not that 
horrible as you said to copy all code. Xen just needs generic freq info 
and method to conduct freq change. All the parse and compatibility issue 
are still taken by dom0 with a new PV interface to report result to Xen.

c) Your patch in another mail is a good one to support on-demand driver 
within dom0. But there're several variants compared to native 
environment:
        * Idle time is not accurate since:
                - idle vcpu may still runs on other processors and then 
run_state 
is not updated
                - the idle snapshot may change before returning to instruction 
after hypercall
        * latency information is inaccurate. On native, the latency basically 
reflects the time consumed on MSR write and de-facto freq change 
accurately. However on this case, the time between (dom0 issues 
WRMSR hypercall) and (Xen finally WRMSR) is even likely larger than 
sample ratio of on-demand driver, if vcpu switch happens in the middle.

        On-demand driver is fine-grained one which only works with 
transition latency <= 10ms. I believe that's a tuned value and it can't be 
always satisfied in virtualization environment. What does such variable 
'latency' make effect to final power saving of on-demand governor? 
Need data to see.

d) I guess final power saving of cpufreq (either approach) is not obvious, 
since average CPU utilization should be higher than native which is the 
goal of virtualization. C-state may be more interesting.

Thanks,
Kevin

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