Re: setitimer timer expires too early

[Nish Aravamudan]

On 4/29/05, Paulo Marques <pmarques@xxxxxxxxxxxx> wrote:
> Olivier Croquette wrote:
> > Hello
> >
> > I wrote a program which uses setitimer to implement a usleep() equivalent.
> > [...]
> > Anyone have an idea?
> > Can you reproduce that?
> 
> I can reproduce that.
> 
> It seems that the code responsible for this is in kernel/itimer.c:126:
> 
>         p->signal->real_timer.expires = jiffies + interval;
>         add_timer(&p->signal->real_timer);
> 
> If you request an interval of, lets say 900 usecs, the interval given by
> timeval_to_jiffies will be 1.

<snip>

> The complex (and more computationally expensive) solution would be to
> check the gettimeofday time, and compute the correct number of jiffies.
> This way, if we request a 300 usecs timer 200 usecs inside the timer
> tick, we can wait just one tick, but not if we are 800 usecs inside the
> tick. This would also mean that we would have to lock preemption during
> these computations to avoid races, etc.

I am working on soft-timer subsystem rework that will do exactly this,
based upon John Stultz's timeofday-rework. Expect to see an RFC soon
:)

> I've searched the archives but couldn't find this particular issue being
> discussed before.

Perhaps not discussed before, but definitely a known issue. Check out
sys_nanosleep(), which adds an extra jiffy to the delay if there is
going to be one. My patch, which uses human-time (or at least more so
than currently), should not have issues like this.
 
> Attached is a patch to do the simple solution, in case anybody thinks
> that it should be used.

Your patch is the only way to guarantee no early timeouts, as far as I know.

Really, what you want is:

on adding timers, take the ceiling of the interval into which it could be added
on expiring timers, take the floor

This combination guarantees no timers go off early (and takes away
many of these corner cases). I do exactly this in my patch, btw.

> Signed-Off-By: Paulo Marques <pmarques@xxxxxxxxxxxx>

Acked-By: Nishanth Aravamudan <nacc@xxxxxxxxxx>

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/