Subject: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 10 Jun 2008 16:39:41 +0100
Package: manpages-dev
Version: 2.79-4
Severity: wishlist
The BUGS section in nanosleep(2) gives:
BUGS
The current implementation of nanosleep() is based on the
normal kernel timer mechanism, which has a resolution of
1/HZ s (see time(7)). Therefore, nanosleep() pauses
always for at least the specified time, however it can
take up to 10 ms longer than specified until the process
becomes runnable again. For the same reason, the value
returned in case of a delivered signal in *rem is usually
rounded to the next larger multiple of 1/HZ s.
Old behavior
In order to support applications requiring much more
precise pauses (e.g., in order to control some
time-critical hardware), nanosleep() would handle pauses
of up to 2 ms by busy waiting with microsecond
precision when called from a process scheduled under a
real-time policy like SCHED_FIFO or SCHED_RR. This
special extension was removed in kernel 2.5.39, hence is
still present in current 2.4 kernels, but not in 2.6
kernels.
In Linux 2.4, if nanosleep() is stopped by a signal
(e.g., SIGTSTP), then the call fails with the error EINTR
after the process is resumed by a SIGCONT signal. If
the system call is subsequently restarted, then the time
that the process spent in the stopped state is not
counted against the sleep interval.
I think it should be worth mentionning that since 2.6.16, on
some architectures, the kernel can be configured with high
resolution timers which makes nanosleep(2) a lot more accurate
and voids the first comment above.
Also, I'm not sure whether the HZ above is the user's HZ (100)
or the kernel HZ (defined at compilation time), it may worth
clarifying.
Other man pages such as setitimer(2) might need to be updated as
well.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-rc8 (PREEMPT)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages manpages-dev depends on:
ii manpages 2.79-4 Manual pages about using a GNU/Lin
manpages-dev recommends no packages.
-- no debconf information
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Wed, 11 Jun 2008 08:52:24 +0200
On Tue, Jun 10, 2008 at 5:39 PM, Stephane Chazelas
<[email protected]> wrote:
> Package: manpages-dev
> Version: 2.79-4
> Severity: wishlist
>
>
> The BUGS section in nanosleep(2) gives:
>
> BUGS
> The current implementation of nanosleep() is based on the
> normal kernel timer mechanism, which has a resolution of
> 1/HZ s (see time(7)). Therefore, nanosleep() pauses
> always for at least the specified time, however it can
> take up to 10 ms longer than specified until the process
> becomes runnable again. For the same reason, the value
> returned in case of a delivered signal in *rem is usually
> rounded to the next larger multiple of 1/HZ s.
>
> Old behavior
> In order to support applications requiring much more
> precise pauses (e.g., in order to control some
> time-critical hardware), nanosleep() would handle pauses
> of up to 2 ms by busy waiting with microsecond
> precision when called from a process scheduled under a
> real-time policy like SCHED_FIFO or SCHED_RR. This
> special extension was removed in kernel 2.5.39, hence is
> still present in current 2.4 kernels, but not in 2.6
> kernels.
>
> In Linux 2.4, if nanosleep() is stopped by a signal
> (e.g., SIGTSTP), then the call fails with the error EINTR
> after the process is resumed by a SIGCONT signal. If
> the system call is subsequently restarted, then the time
> that the process spent in the stopped state is not
> counted against the sleep interval.
>
>
> I think it should be worth mentionning that since 2.6.16, on
> some architectures, the kernel can be configured with high
> resolution timers which makes nanosleep(2) a lot more accurate
> and voids the first comment above.
Stephane
Thanks for your note. Can you provide some further details -- for
example, can you tell me any of the following:
which architectures?
what config options are required?
what determines the accuracy that can be achieved with HR timers?
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution
timers
Date: Wed, 11 Jun 2008 10:16:49 +0100
On Wed, Jun 11, 2008 at 08:52:24AM +0200, Michael Kerrisk wrote:
[...]
> > I think it should be worth mentionning that since 2.6.16, on
> > some architectures, the kernel can be configured with high
> > resolution timers which makes nanosleep(2) a lot more accurate
> > and voids the first comment above.
[...]
> Thanks for your note. Can you provide some further details -- for
> example, can you tell me any of the following:
> which architectures?
> what config options are required?
> what determines the accuracy that can be achieved with HR timers?
[...]
Hi Michael,
sorry, I'm not a kernel developper, so I know very little about
it. I only observed that usleep() became a lot more accurate
since 2.6.16. While usleep(1) was sleeping for about 10ms
before (to the next tick), it now sleeps for about 1µs as
requested when tried on x86 (usleep(3) calls nanosleep(2)).
Last time I checked ARCH=ppc didn't have such support but
ARCH=powerpc did. I don't know about the other architectures,
but that would be a matter of checking the Kconfigs.
It's enabled with CONFIG_HIGH_RES_TIMERS which itself depends on
architecture specific options.
More information can be found in
Documentation/hrtimers/hrtimers.txt in the kernel sources which
says:
The code was successfully compiled for the following platforms:
i386, x86_64, ARM, PPC, PPC64, IA64
The code was run-tested on the following platforms:
i386(UP/SMP), x86_64(UP/SMP), ARM, PPC
hrtimers were also integrated into the -rt tree, along with a
hrtimers-based high-resolution clock implementation, so the hrtimers
code got a healthy amount of testing and use in practice.
regards,
Stéphane
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 09:10:00 +0200
Stephane,
On Wed, Jun 11, 2008 at 11:16 AM, Stephane Chazelas
<[email protected]> wrote:
> On Wed, Jun 11, 2008 at 08:52:24AM +0200, Michael Kerrisk wrote:
> [...]
>> > I think it should be worth mentionning that since 2.6.16, on
>> > some architectures, the kernel can be configured with high
>> > resolution timers which makes nanosleep(2) a lot more accurate
>> > and voids the first comment above.
I've certainly verified this in 2.6.26-rc6. The question is exactly
when the change came about.
> [...]
>> Thanks for your note. Can you provide some further details -- for
>> example, can you tell me any of the following:
>> which architectures?
>> what config options are required?
>> what determines the accuracy that can be achieved with HR timers?
> [...]
>
> Hi Michael,
>
> sorry, I'm not a kernel developper, so I know very little about
> it. I only observed that usleep() became a lot more accurate
> since 2.6.16.
Was that vanilla kernel 2.6.16? I'm tring to track the places where
varios system calls changed to HRTs.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 11:03:24 +0200
On Tue, Jun 24, 2008 at 9:10 AM, Michael Kerrisk
<[email protected]> wrote:
> Stephane,
>
> On Wed, Jun 11, 2008 at 11:16 AM, Stephane Chazelas
> <[email protected]> wrote:
>> On Wed, Jun 11, 2008 at 08:52:24AM +0200, Michael Kerrisk wrote:
>> [...]
>>> > I think it should be worth mentionning that since 2.6.16, on
>>> > some architectures, the kernel can be configured with high
>>> > resolution timers which makes nanosleep(2) a lot more accurate
>>> > and voids the first comment above.
>
> I've certainly verified this in 2.6.26-rc6. The question is exactly
> when the change came about.
>
>> [...]
>>> Thanks for your note. Can you provide some further details -- for
>>> example, can you tell me any of the following:
>>> which architectures?
>>> what config options are required?
>>> what determines the accuracy that can be achieved with HR timers?
>> [...]
>>
>> Hi Michael,
>>
>> sorry, I'm not a kernel developper, so I know very little about
>> it. I only observed that usleep() became a lot more accurate
>> since 2.6.16.
>
> Was that vanilla kernel 2.6.16? I'm tring to track the places where
> varios system calls changed to HRTs.
Hmmm -- I got slightly confused by the fact CONFIG_HIGH_RES_TIMERS
only seems to have been added in 2.6.21.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 11:22:48 +0200
Okay -- as a first step to resolving this, I've adjusted the text in
time.7, including adding a mention of HRTs. The text that I plan to
put in man-pages-3.01 is shown below. Does it look okay to you
Stephane?
The Software Clock, HZ, and Jiffies
The accuracy of various system calls that set timeouts,
(e.g., select(2), sigtimedwait(2)) and measure CPU time
(e.g., getrusage(2)) is limited by the resolution of the
software clock, a clock maintained by the kernel which
measures time in jiffies. The size of a jiffy is deter-
mined by the value of the kernel constant HZ.
The value of HZ varies across kernel versions and hard-
ware platforms. On i386 the situation is as follows: on
kernels up to and including 2.4.x, HZ was 100, giving a
jiffy value of 0.01 seconds; starting with 2.6.0, HZ was
raised to 1000, giving a jiffy of 0.001 seconds. Since
kernel 2.6.13, the HZ value is a kernel configuration
parameter and can be 100, 250 (the default) or 1000,
yielding a jiffies value of, respectively, 0.01, 0.004,
or 0.001 seconds. Since kernel 2.6.20, a further fre-
quency is available: 300, a number that divides evenly
for the common video frame rates (PAL, 25 HZ; NTSC, 30
HZ).
High-Resolution Timers
Before Linux 2.6.16, the accuracy of timer and sleep sys-
tem calls (see below) was also limited by the size of the
jiffy.
Since Linux 2.6.16, Linux supports high-resolution timers
(HRTs), optionally configurable since kernel 2.6.21 via
CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs,
the accuracy of sleep and timer system calls is no longer
constrained by the jiffy, but instead can be as accurate
as the hardware allows (microsecond accuracy is typical
of modern hardware).
...
Sleeping and Setting Timers
Various system calls and functions allow a program to
sleep (suspend execution) for a specified period of time;
see nanosleep(2), clock_nanosleep(2), and sleep(3).
Various system calls allow a process to set a timer that
expires at some point in the future, and optionally at
repeated intervals; see alarm(2), getitimer(2),
timerfd_create(2), and timer_create(3).
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution
timers
Date: Tue, 24 Jun 2008 10:27:19 +0100
On Tue, Jun 24, 2008 at 09:10:00AM +0200, Michael Kerrisk wrote:
[...]
> >> > I think it should be worth mentionning that since 2.6.16, on
> >> > some architectures, the kernel can be configured with high
> >> > resolution timers which makes nanosleep(2) a lot more accurate
> >> > and voids the first comment above.
>
> I've certainly verified this in 2.6.26-rc6. The question is exactly
> when the change came about.
[...]
Hi Michael,
See:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6ba1b91213e81aa92b5cf7539f7d2a94ff54947c
Cheers,
Stéphane
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 11:41:15 +0200
As the last step of resolving this bug, I removed the entire paragraph
that discusses HZ, and added the following paragraph under NOTES:
If the interval specified in req is not an exact multiple of
the granularity underlying clock (see time(7)), then the inter-
val will be rounded up to the next multiple. Furthermore,
after the sleep completes, there may still be a delay before
the CPU becomes free to once again execute the calling thread.
If these changes (which will appear in 3.01) seem okay to you Stepahe,
please tag the bug "fixed-upstream".
Thanks,
Michael
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution
timers
Date: Tue, 24 Jun 2008 11:59:04 +0100
On Tue, Jun 24, 2008 at 11:22:48AM +0200, Michael Kerrisk wrote:
> Okay -- as a first step to resolving this, I've adjusted the text in
> time.7, including adding a mention of HRTs. The text that I plan to
> put in man-pages-3.01 is shown below. Does it look okay to you
> Stephane?
[...]
Michael,
it looks good. But maybe we should mention that the HZ that
decides of the granularity of the timers is the kernel HZ which
is different from the user HZ (always 100 on x86, always 1024 on
ia64... defined through <sys/param.h>).
That kernel HZ is generally hidden to the user, there's no API
to get it.
Also, I can see we can build tick-less kernels nowadays, but I
really don't know what that means exactly.
Please don't take my word on all this. I'm really not the
specialist here, I tend to find all that very confusing. Best
would be to contact the hrtimer authors.
Also, I think it should be pointed out that highres timers are
not available on all architectures.
In kernel/time/Kconfig:
config HIGH_RES_TIMERS
bool "High Resolution Timer Support"
depends on GENERIC_TIME && GENERIC_CLOCKEVENTS
select TICK_ONESHOT
GENERIC_TIME is defined in the arch/*/Kconfig. "ppc" doesn't
have it for instance. There are fewer arches that have
GENERIC_CLOCKEVENTS it seems.
--
Stéphane
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 13:24:17 +0200
On Tue, Jun 24, 2008 at 12:59 PM, Stephane Chazelas
<[email protected]> wrote:
> On Tue, Jun 24, 2008 at 11:22:48AM +0200, Michael Kerrisk wrote:
>> Okay -- as a first step to resolving this, I've adjusted the text in
>> time.7, including adding a mention of HRTs. The text that I plan to
>> put in man-pages-3.01 is shown below. Does it look okay to you
>> Stephane?
> [...]
>
> Michael,
>
> it looks good. But maybe we should mention that the HZ that
> decides of the granularity of the timers is the kernel HZ which
> is different from the user HZ (always 100 on x86, always 1024 on
> ia64... defined through <sys/param.h>).
Well, this is kind of implied in time(7), where I frame the discussion
in terms of jiffies. Do you think that I'm not clear enough there?
> That kernel HZ is generally hidden to the user, there's no API
> to get it.
>
> Also, I can see we can build tick-less kernels nowadays, but I
> really don't know what that means exactly.
IIUC, then instead of scheduling a regular kernel-internal timer that
goes off ("ticks") at every jiffy (e.g., every 4 millisconds), instead
schedule events based on when the are next required ("hmmm -- nothing
is supposed to happen now for 700 milliseconds, so schedule the next
wakeup then")
> Please don't take my word on all this. I'm really not the
> specialist here, I tend to find all that very confusing. Best
> would be to contact the hrtimer authors.
>
> Also, I think it should be pointed out that highres timers are
> not available on all architectures.
>
> In kernel/time/Kconfig:
>
> config HIGH_RES_TIMERS
> bool "High Resolution Timer Support"
> depends on GENERIC_TIME && GENERIC_CLOCKEVENTS
> select TICK_ONESHOT
>
> GENERIC_TIME is defined in the arch/*/Kconfig. "ppc" doesn't
> have it for instance. There are fewer arches that have
> GENERIC_CLOCKEVENTS it seems.
Good point. I added text to time.7 to cover this.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
Source: manpages
Source-Version: 3.01-1
We believe that the bug you reported is fixed in the latest version of
manpages, which is due to be installed in the Debian FTP archive:
manpages-dev_3.01-1_all.deb
to pool/main/m/manpages/manpages-dev_3.01-1_all.deb
manpages_3.01-1.diff.gz
to pool/main/m/manpages/manpages_3.01-1.diff.gz
manpages_3.01-1.dsc
to pool/main/m/manpages/manpages_3.01-1.dsc
manpages_3.01-1_all.deb
to pool/main/m/manpages/manpages_3.01-1_all.deb
manpages_3.01.orig.tar.gz
to pool/main/m/manpages/manpages_3.01.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Joey Schulze <[email protected]> (supplier of updated manpages package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.8
Date: Fri, 27 Jun 2008 15:11:49 +0200
Source: manpages
Binary: manpages manpages-dev
Architecture: source all
Version: 3.01-1
Distribution: unstable
Urgency: low
Maintainer: Martin Schulze <[email protected]>
Changed-By: Joey Schulze <[email protected]>
Description:
manpages - Manual pages about using a GNU/Linux system
manpages-dev - Manual pages about using GNU/Linux for development
Closes: 482979482987485636486920487254
Changes:
manpages (3.01-1) unstable; urgency=low
.
* New upstream version
. inet_aton() is *not* in POSIX.1 (closes: Bug#482979)
. Improvements to inet_pton() (closes: Bug#482987)
. Improvements to nanosleep(2) (closes: Bug#485636)
. Added errors section for scanf(3) (closes: Bug#487254)
. Document guest time in proc(5) (closes: Bug#486920)
Checksums-Sha1:
1605e0806dc4854d3379150ffbb4e9b0eeed5d40 964 manpages_3.01-1.dsc
cfd01d341b259d44f8391789457d52e38bc8d327 1348851 manpages_3.01.orig.tar.gz
22fc4b999ed541f1a17373b152680cb362ecaa8c 46423 manpages_3.01-1.diff.gz
a6379d90da5015dff07767be4223f9699c5d2610 577032 manpages_3.01-1_all.deb
feb3784e22d92755113345b12d4c786c03a74a2e 1403326 manpages-dev_3.01-1_all.deb
Checksums-Sha256:
a7829005f845c3a710d597bbc5d46987f6109d1d50481ed0a27f1892442e2735 964 manpages_3.01-1.dsc
04ff9d05a43c5820a1127efba6caf06a6ba9bd9a98c18cd93f38ff3446c7c236 1348851 manpages_3.01.orig.tar.gz
c3352a5cb9c80f0fdf88fb29c3011397177186d45b856eb8cc0341b8fc2ac156 46423 manpages_3.01-1.diff.gz
8104d0c7bde81f81d52a85ba20bec58f2d58ae108fb8f37f4cdebdf2811ba1e7 577032 manpages_3.01-1_all.deb
e7da5ca23627565dce0fb8c77ea3f248408f8b9bf4d83d67f626e94f9cb0d0e8 1403326 manpages-dev_3.01-1_all.deb
Files:
0ce201ebec8b8d10bc745683d6a525fc 964 doc important manpages_3.01-1.dsc
5afc311cf7b96d08e17af30f566b1887 1348851 doc important manpages_3.01.orig.tar.gz
f2d94a71cc35c7dc99d0cd48d63480d4 46423 doc important manpages_3.01-1.diff.gz
1d8ffc83c891573da6bcbc04a5043982 577032 doc important manpages_3.01-1_all.deb
68a2acbedea8fde5d3e4bedb06a6aaa6 1403326 doc optional manpages-dev_3.01-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFIZOfHW5ql+IAeqTIRAnIJAJ9liGLBOO9JmDmBuWCRH6Acgi0ThQCfe4AO
VpHRgibtbO0kTIl+qz19MDU=
=EyFw
-----END PGP SIGNATURE-----