Re: Re: [PATCH] xen: always handle VIRQ_TIMER first.

[Jeremy Fitzhardinge <jeremy@goop.org>]

 On 10/16/2010 12:14 AM, Keir Fraser wrote:
> On 15/10/2010 22:11, "Jeremy Fitzhardinge" <jeremy@goop.org> wrote:
>
>>> When guest resumes execution after a long period blocked, the unblocking
>>> interrupt may be handled before the inevitable timer interrupt which
>> Why "inevitable"?  What if the next timer event is still some time in
>> the future?  Or are you assuming the timer is driven by the default Xen
>> 100Hz timer?
> Do you sometimes disable, or indeed never use, VCPUOP_set_periodic_timer?

I disable it ASAP at boot and always use VCPUOP_set_singleshot_timer
from then on.

> Hmmm... Perhaps as you suggest this would be a generic issue with any
> tickless kernel, and the correct upstream fix for issues such as USB kbd
> repeat -- if indeed such issues still exist -- is to fix such hardirq
> handlers to not depend on jiffies.
>
> We fixed it the way we did in 'classic Xen' patched kernels since it seemed
> arhitecturally neatest. I can accept that in the tickless kernel world that
> may not actually be true.

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)
{
	...
}



    J