Debian Bug report logs - #485636
manpages-dev: nanosleep(2) and high resolution timers

version graph

Package: manpages-dev; Maintainer for manpages-dev is Martin Schulze <joey@debian.org>; Source for manpages-dev is src:manpages.

Reported by: Stephane Chazelas <stephane_chazelas@yahoo.fr>

Date: Tue, 10 Jun 2008 15:48:02 UTC

Severity: wishlist

Found in version manpages/2.79-4

Fixed in version manpages/3.01-1

Done: Joey Schulze <joey@infodrom.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to Stephane Chazelas <stephane_chazelas@yahoo.fr>:
New Bug report received and forwarded. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Stephane Chazelas <stephane_chazelas@yahoo.fr>
To: Debian Bug Tracking System <submit@bugs.debian.org>
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #10 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <stephane_chazelas@yahoo.fr>, 485636@bugs.debian.org
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
<stephane_chazelas@yahoo.fr> 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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #15 received at 485636@bugs.debian.org (full text, mbox):

From: Stephane Chazelas <Stephane_Chazelas@yahoo.fr>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: 485636@bugs.debian.org
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #20 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
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
<Stephane_Chazelas@yahoo.fr> 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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #25 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
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
<mtk.manpages@googlemail.com> wrote:
> Stephane,
>
> On Wed, Jun 11, 2008 at 11:16 AM, Stephane Chazelas
> <Stephane_Chazelas@yahoo.fr> 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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #30 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
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).




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #35 received at 485636@bugs.debian.org (full text, mbox):

From: Stephane Chazelas <Stephane_Chazelas@yahoo.fr>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: 485636@bugs.debian.org
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #40 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
Subject: Re: Bug#485636: manpages-dev: nanosleep(2) and high resolution timers
Date: Tue, 24 Jun 2008 11:29:15 +0200
On Tue, Jun 24, 2008 at 11:27 AM, Stephane Chazelas
<Stephane_Chazelas@yahoo.fr> wrote:
> 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

Thanks -- I did eventually verify when the change occurred by looking
at old source tree.


-- 
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #45 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to Stephane Chazelas <Stephane_Chazelas@yahoo.fr>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #50 received at 485636@bugs.debian.org (full text, mbox):

From: Stephane Chazelas <Stephane_Chazelas@yahoo.fr>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: 485636@bugs.debian.org
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




Information forwarded to debian-bugs-dist@lists.debian.org, Martin Schulze <joey@debian.org>:
Bug#485636; Package manpages-dev. Full text and rfc822 format available.

Acknowledgement sent to "Michael Kerrisk" <mtk.manpages@googlemail.com>:
Extra info received and forwarded to list. Copy sent to Martin Schulze <joey@debian.org>. Full text and rfc822 format available.

Message #55 received at 485636@bugs.debian.org (full text, mbox):

From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Stephane Chazelas" <Stephane_Chazelas@yahoo.fr>
Cc: 485636@bugs.debian.org
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
<Stephane_Chazelas@yahoo.fr> 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




Reply sent to Joey Schulze <joey@infodrom.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Stephane Chazelas <stephane_chazelas@yahoo.fr>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #60 received at 485636-close@bugs.debian.org (full text, mbox):

From: Joey Schulze <joey@infodrom.org>
To: 485636-close@bugs.debian.org
Subject: Bug#485636: fixed in manpages 3.01-1
Date: Fri, 27 Jun 2008 13:32:04 +0000
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 485636@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joey Schulze <joey@infodrom.org> (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 ftpmaster@debian.org)


-----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 <joey@debian.org>
Changed-By: Joey Schulze <joey@infodrom.org>
Description: 
 manpages   - Manual pages about using a GNU/Linux system
 manpages-dev - Manual pages about using GNU/Linux for development
Closes: 482979 482987 485636 486920 487254
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-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 07 Aug 2008 07:29:10 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 12:13:01 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.