[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.