RE: [Xen-devel] Problems with enabling hypervisor C and P-state control

["Yu, Ke" <ke.yu@xxxxxxxxx>]

Niraj Tolia wrote:
> 
> Hi Ke,
> 
> This seems to "work" but xenpm doesn't seem to be giving me the right
> data. On a completely idle system, the residency time of state C1 is
> 0ms. xentrace does report a large number of transitions though but
> they seem to be in rapid succession. Is this correct?
> 
> CPU4  320429115477 (+24006897)  cpu_idle_exit   [ C1 -> C0 ]
> CPU4  320429118141 (+    2664)  cpu_idle_entry  [ C0 -> C1 ]
> CPU4  320437500021 (+ 8381880)  cpu_idle_exit   [ C1 -> C0 ]
> CPU4  320437505493 (+    5472)  cpu_idle_entry  [ C0 -> C1 ]
> CPU4  320453123229 (+15617736)  cpu_idle_exit   [ C1 -> C0 ]
> CPU4  320453125992 (+    2763)  cpu_idle_entry  [ C0 -> C1 ]
> CPU4  320477132295 (+24006303)  cpu_idle_exit   [ C1 -> C0 ]
> CPU4  320477134968 (+    2673)  cpu_idle_entry  [ C0 -> C1 ]

Glad to see it "works" :) and thank for your feedback, it is valuable to us in 
term of improving the Xen PM functionality.

You are right, the output is not correct. And the root cause is xen PM 
statistics logic does not record the C1 time. The "hlt" C1 time can not be 
accurately calculated due to interrupt, so we hesitate to record the inaccurate 
value originally. Since now linux kernel already has the "near to accurate" C1 
time accouting, we are planing to port that patch to Xen. After that, xenpm 
will show correct info.

> 
> 
> Second, when I look at the P-state output (shown below), xenpm shows
> that the lowest P-state is only set on the first socket (this is a
> quad-core, quad-socket system). However, I have a feeling that this
> might be a problem with displaying the data rather than the underlying
> logic. Any ideas?
> 
> # xenpm | grep '*'
> *P3                  : freq       [1599 MHz]
> *P3                  : freq       [1599 MHz]
> *P3                  : freq       [1599 MHz]
> *P3                  : freq       [1599 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]
> *P0                  : freq       [2398 MHz]

This seems a bug. From the above info, I can not decided if it is xenpm issue 
or xen cpufreq issue. could you please provide more info, e.g.
- xen boot log (with loglvl=info), so that we can see if cpufreq driver is 
initialized in all cpus
- xentrace date on Px state, so that we can see if the Px transition really 
happened.

Best Regards
Ke

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


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