| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] xen: always handle VIRQ_TIMER first.
On 10/16/2010 12:14 AM, Keir Fraser wrote:
> On 15/10/2010 22:11, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home