|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] xen: always handle VIRQ_TIMER first.
On 10/18/2010 06:20 AM, Jan Beulich wrote:
>>>> On 17.10.10 at 08:11, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>> I think (but I haven't spelunked into that code lately) that after a
>> tickless idle period it will update jiffies N ticks based on the
>> clocksource, and then run any other interrupt handler code, so jiffies
>> will always appear to be up to date.
>>
>> Ah, yes, here it is:
>>
>> /**
>> * tick_nohz_update_jiffies - update jiffies when idle was interrupted
>> *
>> * Called from interrupt entry when the CPU was idle
>> *
>> * In case the sched_tick was stopped on this CPU, we have to check if
>> jiffies
>> * must be updated. Otherwise an interrupt handler could use a stale jiffy
>> * value. We do this unconditionally on any cpu, as we don't know whether
>> the
>> * cpu, which has the update task assigned is in a long sleep.
>> */
>> static void tick_nohz_update_jiffies(ktime_t now)
>> {
>> ...
>> }
> But this is available only with CONFIG_NO_HZ, which is a freely
> selectable option. So perhaps the code should still be added
> inside an #ifndef CONFIG_NO_HZ?
Non-NO_HZ is a pretty pessimal configuration for a VM, or indeed any
system which cares about power. Are there any use cases for which its a
good idea?
However, you could change it to always update jiffies on any interrupt
entrypoint, regardless of whether its coming from an idle state. Or
even just change "jiffies" into a macro which calls a function to just
compute the current value without needing to rely on interrupts at all.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|