mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk.manpages@googlemail.com>
To: "Bart Van Assche" <bart.vanassche@gmail.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@elte.hu>,
	lkml <linux-kernel@vger.kernel.org>,
	"Roman Zippel" <zippel@linux-m68k.org>,
	"john stultz" <johnstul@us.ibm.com>,
	"Subrata Modak" <subrata@linux.vnet.ibm.com>,
	"Stephane Chazelas" <stephane_chazelas@yahoo.fr>
Subject: Re: When did High-Resolution Timers hit mainline?
Date: Wed, 25 Jun 2008 16:11:46 +0200	[thread overview]
Message-ID: <cfd18e0f0806250711l6b723dbbs621ee51db07e0d73@mail.gmail.com> (raw)
In-Reply-To: <cfd18e0f0806250633j2901aa89u5609f1b9a4a37dc6@mail.gmail.com>

With the suggestions from Bart and Thomas, I've now reworked the text
as below.  Seem okay now?

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

       The  times(2)  system call is a special case.  It reports times
       with a granularity defined  by  the  kernel  constant  USER_HZ.
       Userspace applications can determine the value of this constant
       using sysconf(_SC_CLK_TCK).

   High-Resolution Timers
       Before Linux 2.6.21, the accuracy of  timer  and  sleep  system
       calls (see below) was also limited by the size of the jiffy.

       Since  Linux  2.6.21,  Linux  supports  high-resolution  timers
       (HRTs), optionally configurable 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).   You  can  determine  whether
       high-resolution timers are supported by checking the resolution
       returned by  a  call  to  clock_getres(3)  or  looking  at  the
       "resolution" entries in /proc/timer_list.

       HRTs are not supported on all hardware architectures.  (Support
       is provided on x86, arm, and powerpc, among others.)
   ...
   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).
==END==

  reply	other threads:[~2008-06-25 14:11 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
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 [this message]
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=cfd18e0f0806250711l6b723dbbs621ee51db07e0d73@mail.gmail.com \
    --to=mtk.manpages@googlemail.com \
    --cc=bart.vanassche@gmail.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stephane_chazelas@yahoo.fr \
    --cc=subrata@linux.vnet.ibm.com \
    --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®