mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Thomas Gleixner" <tglx@linutronix.de>, "Ingo Molnar" <mingo@elte.hu>
Cc: lkml <linux-kernel@vger.kernel.org>,
	"Roman Zippel" <zippel@linux-m68k.org>,
	"john stultz" <johnstul@us.ibm.com>
Subject: Re: When did High-Resolution Timers hit mainline?
Date: Wed, 25 Jun 2008 06:08:53 +0200	[thread overview]
Message-ID: <cfd18e0f0806242108s79ccc948n73e2ad5f694ecdaf@mail.gmail.com> (raw)
In-Reply-To: <cfd18e0f0806232335p3e05d690o5a5cef8c9626fae7@mail.gmail.com>

On Tue, Jun 24, 2008 at 8:35 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
> Hi Ingo, Thomas,
>
> I want to update some timer and sleep man pages to reflect the arrival
> of high-resolution timers.  However, it's not quite clear to me when
> HRTs properly arrived in mainline.  Was it 2.6.21?  And at that point,
> was the resolution for all timer and sleep calls based on HRTs, so
> that they all became more accurate?  (Or was it the case that various
> system calls switched over to HRTs in different later kernel
> versions?)  Specifically, I'm thinking of the following system calls
>
> nanosleep()
> clock_nanosleep()
> setitimer()
> timer_create()/timer_settime()
>
> Was it the case that pre 2.6.21 (or whatever) these were all
> jiffy-based in their accuracy, and then post 2.6.21, they were all HRT
> based (if CONFIG_HIGH_RES_TIMERS is enabled)?

So I got confused by the fact that CONFIG_HIGH_RES_TIMERS only
appeared in 2.6.21.  I plan to include the following text to time(7)
for the next man-pages release.  Does it look okay?

Cheers,

Michael

   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 determined by the value of the
       kernel constant HZ.

       The  value  of  HZ  varies  across kernel versions and hardware
       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,  giv-
       ing  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, respec-
       tively, 0.01, 0.004, or 0.001 seconds.  Since kernel 2.6.20,  a
       further  frequency  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 system
       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 CON-
       FIG_HIGH_RES_TIMERS.  On a system that supports HRTs, the accu-
       racy  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).

       HRTs are not supported on all hardware architectures.  (Support
       is provided on x86, arm, and powerpc, among others.)

  reply	other threads:[~2008-06-25  4:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24  6:35 Michael Kerrisk
2008-06-25  4:08 ` Michael Kerrisk [this message]
2008-06-25  6:32   ` Bart Van Assche
2008-06-25 12:16     ` Michael Kerrisk
2008-06-25 13:33     ` Michael Kerrisk
2008-06-25 14:11       ` Michael Kerrisk
2008-06-25  7:09   ` Thomas Gleixner
2008-06-25 12:20     ` Michael Kerrisk
2008-06-25 12:22       ` Thomas Gleixner
2008-06-25 12:25         ` Michael Kerrisk

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=cfd18e0f0806242108s79ccc948n73e2ad5f694ecdaf@mail.gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=zippel@linux-m68k.org \
    /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

all inboxes | Powered by JetHome®