linux-kernel - Re: When did High-Resolution Timers hit mainline?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cfd18e0f0806242108s79ccc948n73e2ad5f694ecdaf@mail.gmail.com>
Date:	Wed, 25 Jun 2008 06:08:53 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"Roman Zippel" <zippel@...ux-m68k.org>,
	"john stultz" <johnstul@...ibm.com>
Subject: Re: When did High-Resolution Timers hit mainline?

On Tue, Jun 24, 2008 at 8:35 AM, Michael Kerrisk
<mtk.manpages@...glemail.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.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/