From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Paulo Marques <pmarques@grupopie.com>
Cc: Olivier Croquette <ocroquette@free.fr>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: setitimer timer expires too early
Date: Fri, 29 Apr 2005 14:25:32 -0700 [thread overview]
Message-ID: <29495f1d050429142515f7e2c4@mail.gmail.com> (raw)
In-Reply-To: <427285CC.9090300@grupopie.com>
On 4/29/05, Paulo Marques <pmarques@grupopie.com> 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@grupopie.com>
Acked-By: Nishanth Aravamudan <nacc@us.ibm.com>
Thanks,
Nish
next prev parent reply other threads:[~2005-04-29 21:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-29 17:24 setitimer timer expires too early Olivier Croquette
2005-04-29 19:06 ` Paulo Marques
2005-04-29 21:25 ` Nish Aravamudan [this message]
2005-04-30 15:32 ` Olivier Croquette
2005-05-02 6:07 ` Nish Aravamudan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29495f1d050429142515f7e2c4@mail.gmail.com \
--to=nish.aravamudan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ocroquette@free.fr \
--cc=pmarques@grupopie.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox