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
On Tue, Jun 24, 2008 at 8:35 AM, Michael Kerrisk
<[email protected]> 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.)
On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
<[email protected]> 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.
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
Hi Bart,
Thanks for taking a look at this.
On Wed, Jun 25, 2008 at 8:32 AM, Bart Van Assche
<[email protected]> wrote:
> On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
> <[email protected]> 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
Thomas,
On Wed, Jun 25, 2008 at 9:09 AM, Thomas Gleixner <[email protected]> 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
On Wed, Jun 25, 2008 at 2:22 PM, Thomas Gleixner <[email protected]> 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
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
Hi Bart,
Just following up a little further here.
On Wed, Jun 25, 2008 at 8:32 AM, Bart Van Assche
<[email protected]> wrote:
> On Wed, Jun 25, 2008 at 6:08 AM, Michael Kerrisk
> <[email protected]> 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
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==