>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>On 20/03/2009 12:51, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>> cpuidle can collaborate with scheduler to reduce unnecessary timer interrupt.
>> For example, credit scheduler accounting timer doesn't need to be active at
>> idle time, so it can be stopped at cpuidle entry and resumed at cpuidle exit.
>> This patch implements this function by adding two ops in scheduler:
>> tick_suspend/tick_resume, and implement them for credit scheduler
>> With this patch, under idle scenario, timer interrupt frequency decreased
>> ~100HZ to ~10HZ, and average C state residency increase from ~10ms to larger
>> than 100ms. Also in a two-socket machine, about 4% idle power saving is
>> However, one issue is observed with this patch, i.e. there is soft-lockup in
>> dom0 occasionally. This issue is still under debugging. Currently we already
>> find a >1s VCPUOP_set_singleshot_timer timeout, which imply this may be a
>> issue. we are working hard to figure the root cause.
>I don't really want to take the patch while it is soft locking up. I would
>expect linux-2.6.18-xen.hg:22 to avoid lockup warnings due to too long
>singleshot timeouts (I assume you are testing with the 2.6.18 tree?).
Right, I am testing it with 2.6.18 tree. I am also looking into the dom0 code,
to see if should change dom0.
>Personally I would rather have cpuidle be enabled by default (or even always
>with no disable option) and get existing Cx benefits for everyone, rather
>than have a slightly broken cpuidle option.
>Is there a reason not to turn on cpuidle by default now? Or even enable and
>then remove the boot option?
There is no obvious obstacle to turn on cpuidle by default. According to our
testing and measurement, cpuidle is pretty stable now, maybe it is time to
enable it by default.
Xen-devel mailing list