When did High-Resolution Timers hit mainline?

When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

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

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

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

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

Re: When did High-Resolution Timers hit mainline?

[Bart Van Assche]

On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
>   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.

Maybe "size of a jiffy" should be replaced by "duration of a jiffy" ?

An explanation of the impact of CONFIG_NO_HZ is missing.

You also missed the fact that since the 2.6 kernel there are two
constants related to time resolution, namely HZ and USER_HZ. HZ is the
frequency of the timer interrupt, and 1/USER_HZ is the time resolution
for system calls that use jiffies as time unit (e.g. the five values
returned by the times() system call). The time resolution of e.g. the
select() and poll() system calls is 1.0/HZ since the timeout for these
system calls is specified as a struct timeval or struct timespec.

Bart.

Re: When did High-Resolution Timers hit mainline?

[Thomas Gleixner]

On Wed, 25 Jun 2008, Michael Kerrisk wrote:
>    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).

Hmm, that's a bit backwards. We changed the internal handling of those
interfaces to hrtimers in 2.6.16, but the accuracy is still jiffies
unless you have CONFIG_HIGH_RES_TIMERS enabled (which is only possible
as of 2.6.21) and your system provides the necessary hardware.
 
>        HRTs are not supported on all hardware architectures.  (Support
>        is provided on x86, arm, and powerpc, among others.)

Also you might point out that you can check whether high resolution
timers are active via clock_getres() or by checking the resolution
entry in /proc/timer_list.

Thanks,

	tglx

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

Hi Bart,

Thanks for taking a look at this.

On Wed, Jun 25, 2008 at 8:32 AM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>>   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.
>
> Maybe "size of a jiffy" should be replaced by "duration of a jiffy" ?

Actually, IMO size feels better in this context.

> An explanation of the impact of CONFIG_NO_HZ is missing.

I'm not sure whether it's needed here.  Can you say a little more
about why you think something needs to be said (and perhaps even
suggest some text then)?

> You also missed the fact that since the 2.6 kernel there are two
> constants related to time resolution, namely HZ and USER_HZ. HZ is the
> frequency of the timer interrupt, and 1/USER_HZ is the time resolution
> for system calls that use jiffies as time unit (e.g. the five values
> returned by the times() system call). The time resolution of e.g. the
> select() and poll() system calls is 1.0/HZ since the timeout for these
> system calls is specified as a struct timeval or struct timespec.

Good point!  I will come up with some text for this.

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

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

Thomas,

On Wed, Jun 25, 2008 at 9:09 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 25 Jun 2008, Michael Kerrisk wrote:
>>    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).
>
> Hmm, that's a bit backwards. We changed the internal handling of those
> interfaces to hrtimers in 2.6.16, but the accuracy is still jiffies
> unless you have CONFIG_HIGH_RES_TIMERS enabled (which is only possible
> as of 2.6.21) and your system provides the necessary hardware.

So then it's simply enough to say:

Since  Linux  2.6.17,  Linux  optionaly supports  high-resolution  timers
(configurable via CONFIG_HIGH_RES_TIMERS).

right?

>>        HRTs are not supported on all hardware architectures.  (Support
>>        is provided on x86, arm, and powerpc, among others.)
>
> Also you might point out that you can check whether high resolution
> timers are active via clock_getres() or by checking the resolution
> entry in /proc/timer_list.

Okay -- thanks.

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

Re: When did High-Resolution Timers hit mainline?

[Thomas Gleixner]

On Wed, 25 Jun 2008, Michael Kerrisk wrote:
> > Hmm, that's a bit backwards. We changed the internal handling of those
> > interfaces to hrtimers in 2.6.16, but the accuracy is still jiffies
> > unless you have CONFIG_HIGH_RES_TIMERS enabled (which is only possible
> > as of 2.6.21) and your system provides the necessary hardware.
> 
> So then it's simply enough to say:
> 
> Since  Linux  2.6.17,  Linux  optionaly supports  high-resolution  timers
> (configurable via CONFIG_HIGH_RES_TIMERS).
>
> right?

Make this 2.6.21 :)

Thanks,
	tglx

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

On Wed, Jun 25, 2008 at 2:22 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 25 Jun 2008, Michael Kerrisk wrote:
>> > Hmm, that's a bit backwards. We changed the internal handling of those
>> > interfaces to hrtimers in 2.6.16, but the accuracy is still jiffies
>> > unless you have CONFIG_HIGH_RES_TIMERS enabled (which is only possible
>> > as of 2.6.21) and your system provides the necessary hardware.
>>
>> So then it's simply enough to say:
>>
>> Since  Linux  2.6.17,  Linux  optionaly supports  high-resolution  timers
>> (configurable via CONFIG_HIGH_RES_TIMERS).
>>
>> right?
>
> Make this 2.6.21 :)

D'oh!  Yes of course.  Fingers were working, but Mr. Brain had long
since departed...

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

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

Hi Bart,

Just following up a little further here.

On Wed, Jun 25, 2008 at 8:32 AM, Bart Van Assche
<bart.vanassche@gmail.com> wrote:
> On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
> <mtk.manpages@googlemail.com> wrote:
>>   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.
>
> Maybe "size of a jiffy" should be replaced by "duration of a jiffy" ?
>
> An explanation of the impact of CONFIG_NO_HZ is missing.
>
> You also missed the fact that since the 2.6 kernel there are two
> constants related to time resolution, namely HZ and USER_HZ. HZ is the
> frequency of the timer interrupt, and 1/USER_HZ is the time resolution
> for system calls that use jiffies as time unit (e.g. the five values
> returned by the times() system call).

As far as I can tell, times() is the only system call that employs
USER_HZ.  Let me know if you think I'm wrong.  The only othe place
where USER_HZ seems to come into play is the time fields displayed in
/proc/PID/stat and /poc/stat.  (My point of verification here is
looking at usages of cputime_to_clock_t() and cputime64_to_clock_t()
in the kernel source.)

> The time resolution of e.g. the
> select() and poll() system calls is 1.0/HZ since the timeout for these
> system calls is specified as a struct timeval or struct timespec.

Yes.  So I think what I'll do is just add some text noting that the
times() syscall is a special case.

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

Re: When did High-Resolution Timers hit mainline?

[Michael Kerrisk]

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