From: Tom Marshall <tmarshall@real.com>
To: Paulo Marques <pmarques@grupopie.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: itimer oddness in 2.6.12
Date: Fri, 22 Jul 2005 13:58:25 -0700 [thread overview]
Message-ID: <20050722205825.GB6476@real.com> (raw)
In-Reply-To: <42E14735.1090205@grupopie.com>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
On Fri, Jul 22, 2005 at 08:21:25PM +0100, Paulo Marques wrote:
> Tom Marshall wrote:
> >The patch to fix "setitimer timer expires too early" is causing issues for
> >the Helix server. We have a timer processs that updates the server's
> >timestamp on an itimer and it expects the signal to be delivered at roughly
> >the interval retrieved from getitimer. This is very consistent on every
> >platform, including Linux up to 2.6.11, but breaks on 2.6.12. On 2.6.12,
> >setting the itimer to 10ms and retrieving the actual interval from
> >getitimer
> >reports 10.998ms, but the timer interrupts are consistently delivered at
> >roughly 11.998ms.
>
> Unfortunately, this is not so clear cut as it seems :(
Yes, I am sure that it is not a simple problem. I am not a kernel developer
but I imagine that issues such as NTP adjustments would complicate this
issue. I must also admit that I am not intimately familiar with the POSIX
spec regarding itimers.
Our current code does a setitimer followed by getitimer, then uses the
actual interval retrieved by getitimer to set a global timer delta. On each
timer signal, it updates the notion of the current time by the timer delta.
As mentioned, this works on every other platform (Solaris, BSD, HPUX, AIX,
DGUX, IRIX, Tru64, and Linux up to 2.6.11) but breaks on 2.6.12.
This is not an insurmountable problem for userspace. It can be easily
solved by using gettimeofday in the timer interrupt instead of adding the
delta to the current time blindly. No big deal. I just wanted to point
this issue out and ensure that (1) it was a known issue, and (2) it is the
direction that the Linux kernel intends to take. If so, no big deal and we
can modify the timer code to take that into account.
--
Apathy Club meeting this Friday. If you want to come, you're not invited.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-22 20:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 17:16 itimer oddness in 2.6.12 Tom Marshall
2005-07-22 19:21 ` Paulo Marques
2005-07-22 20:58 ` Tom Marshall [this message]
2005-07-23 1:48 ` [PATCH] " George Anzinger
2005-07-25 11:58 ` Paulo Marques
2005-07-25 19:04 ` Bill Davidsen
2005-07-26 6:17 ` Andrew Morton
2005-07-26 14:36 ` George Anzinger
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=20050722205825.GB6476@real.com \
--to=tmarshall@real.com \
--cc=linux-kernel@vger.kernel.org \
--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