Someone reported they could spin over twenty times before a soon-to-occur
jiffy ''tick'' (specifically, the ''jiffies+1''
tick) actually occurred. Which
makes sense since the ''slop'' in Xen''s
timer_softirq_action() is 50us and the
cost of block-plus-wakeup-on-VIRQ_TIMER is about a couple of microseconds.
So that''s over twenty times setting a timeout less than 50us in the
future,
blocking, immediately waking up in the timer ISR, doing no work, setting a
timeout... etc.
So the patch avoids this little corner case. It''s not a major issue,
and the
side effect is that you may wait a little longer to do timer work.
-- Keir
On 2/6/08 08:46, "Jan Beulich" <jbeulich@novell.com> wrote:
> Keir,
>
> this change looks a little odd to me - the code as it was before already
> set the timeout to jiffies + 1 as the lowest possible value. So I
don''t
> understand how you could have observed any spinning over more than
> really short periods of time (where you happen to just see jiffies
> increment while setting the timeout).
>
> I''d therefore appreciate any insight to the background of that
change.
>
> Thanks, Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel