Re: [Xen-devel] Singleshot timer firing late

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On Mon, 2014-05-19 at 12:24 +0100, Jan Beulich wrote:
> >>> On 19.05.14 at 12:42, <ross.lagerwall@xxxxxxxxxx> wrote:
> > While investigating a separate timer issue, I noticed that, in the
> > absence of other timers/factors, singleshot timers in Xen always fire
> > 50us late (the timer slop amount).
> > 
> > From what I can see, this behavior was introduced by 116d62ddfd11
> > ("timers: Simplify implementation logic.").  Before that, a similar
> > issue was fixed by 7e3e35eed67b ("Fix one timer range issue").
> > 
> > I have attached an RFC patch to program the timer to the nearest
> > deadline and then fire any timers up to 50us after that.  This is in
> > contrast with the previous behavior which would always program the
> > timer 50us after the nearest deadline.
> 
> While the patch may certainly do what you want, you don't give
> enough explanation of why this is what every one wants. Plus
> firing timers early is precisely what we _do not_ want in general.
> Furthermore, if this 50ms slop is of concern to you, using the
> corresponding command line option to shrink or eliminate it would
> be the first thing to try anyway - that's why the command line
> option was added after all.
> 

Well, currently in the absence of other timers, the timer will always
fire 50us late.  If there are multiple deadlines within 50us, then some
of them may fire less than 50us late.

The last email's patch changes it so that in the absence of other
timers, the timer will fire on time.  If there are multiple deadlines
within 50us, then some of them may fire up to 50us early.  As far as I
can tell, this would give a smaller average latency (and restore the
behavior to what it was before 116d62ddfd11, which gave no reason for
the change).  Of course, if firing timers early is a problem then this
approach should not be taken.

Here's another patch which programs the timer to the deadline of the
closest timer if it is further than 50us ahead, otherwise it sets it
50us ahead. This way a single event fires on time and events don't fire
early.  I think this behaves like Linux clockevent's min_delta_ns.

Regards
Ross

Attachment: fix-late-timers.patch
Description: fix-late-timers.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel