For review: timer_settime.2

For review: timer_settime.2

[Michael Kerrisk]

Hello all,

Again, looking for reviewers for this page for timer_settime(2)
and timer_gettime(2).  Formatted output, and groff source below.

Cheers,

Michael


NAME
       timer_settime,  timer_gettime  -  arm/disarm and fetch state of
       POSIX per-process timer

SYNOPSIS
       #include <time.h>

       int timer_settime(timer_t timerid, int flags,
                         const struct itimerspec *new_value,
                         struct itimerspec * old_value);
       int timer_gettime(timer_t timerid, struct itimerspec *curr_value);

       Link with -lrt.

   Feature   Test   Macro   Requirements   for   glibc    (see    fea-
   ture_test_macros(7)):

       timer_settime(), timer_gettime(): _POSIX_C_SOURCE >= 199309

DESCRIPTION
       timer_settime()   arms  or  disarms  the  timer  identified  by
       timerid.  The new_value argument  is  an  itimerspec  structure
       that  specifies  the new initial value and the new interval for
       the timer.  The itimerspec structure is defined as follows:

           struct timespec {
               time_t tv_sec;                /* Seconds */
               long   tv_nsec;               /* Nanoseconds */
           };

           struct itimerspec {
               struct timespec it_interval;  /* Timer interval */
               struct timespec it_value;     /* Initial expiration */
           };

       Each of the substructures of  the  itimerspec  structure  is  a
       timespec  structure that allows a time value to be specified in
       seconds  and  nanoseconds.   These  time  values  are  measured
       according  to  the  clock that was specified when the timer was
       created by timer_create()

       If new_value->it_value specifies a non-zero value (i.e., either
       subfield  is  non-zero), then timer_settime() arms (starts) the
       timer, setting it to initially expire at the given  time.   (If
       the  timer  was  already  armed, then the previous settings are
       overwritten.)  If new_value->it_value specifies  a  zero  value
       (i.e., both subfields are zero), then the timer is disarmed.

       The  new_value->it_interval  field  specifies the period of the
       timer, in seconds and nanoseconds.  If this field is  non-zero,
       then  each  time  that  an  armed  timer  expires, the timer is
       reloaded from the value  specified  in  new_value->it_interval.
       If new_value->it_interval specifies a zero value then the timer
       expires just once, at the time specified by it_value.

       By  default,  the  initial   expiration   time   specified   in
       new_value->it_value is interpreted relative to the current time
       on the timer's clock at the time of the call.  This can be mod-
       ified  by  specifying  TIMER_ABSTIME  in  flags,  in which case
       new_value->it_value is interpreted as an absolute value as mea-
       sured on the timer's clock; that is, the timer will expire when
       the   clock   value   reaches   the    value    specified    by
       new_value->it_value.    If  the  specified  absolute  time  has
       already passed, then the timer  expires  immediately,  and  the
       overrun  count (see timer_getoverrun(2)) will be set correctly.

       If the value of the CLOCK_REALTIME clock is adjusted  while  an
       absolute  timer  based on that clock is armed, then the expira-
       tion of the timer will be appropriately adjusted.   Adjustments
       to  the  CLOCK_REALTIME clock have no effect on relative timers
       based on that clock.

       If old_value is not NULL, then it returns the previous interval
       of the timer (in old_value->it_interval) and the amount of time
       until  the  timer  would  previously  have  next  expired   (in
       old_value->it_value).

       timer_gettime() returns the time until next expiration, and the
       the interval, for the timer specified by timerid, in the buffer
       pointed  to  by  curr_value.  The time remaining until the next
       timer expiration is returned in  curr_value.it_value;  this  is
       always   a   relative   value,   regardless   of   whether  the
       TIMER_ABSTIME flag was used when  arming  the  timer.   If  the
       value  returned  in curr_value.it_value is zero, then the timer
       is currently disarmed.   The  timer  interval  is  returned  in
       curr_value.it_interval.     If    the    value    returned   in
       curr_value.it_interval is  zero,  then  this  is  a  "one-shot"
       timer.

RETURN VALUE
       On  success,  timer_settime() and timer_gettime() return 0.  On
       error, -1 is returned, and errno is set to indicate the  error.

ERRORS
       These functions may fail with the following errors:

       EFAULT new_value,  old_value,  or  curr_value  is  not  valid a
              pointer.

       EINVAL timerid is invalid.

       timer_settime() may fail with the following errors:

       EINVAL new_value.it_value        is        negative;         or
              new_value.it_value.tv_nsec  is  negative or greater than
              999,999,999.

VERSIONS
       These system calls are available since Linux 2.6.

CONFORMING TO
       POSIX.1-2001

SEE ALSO
       timer_create(2), timer_settime(2), timer_getoverrun(2), time(7)



.\" Copyright (c) 2009 Linux Foundation, written by Michael Kerrisk
.\"     <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.TH TIMER_SETTIME 2 2009-02-16 Linux "Linux Programmer's Manual"
.SH NAME
timer_settime, timer_gettime \- arm/disarm and fetch
state of POSIX per-process timer
.SH SYNOPSIS
.nf
.B  #include <time.h>

.BI "int timer_settime(timer_t " timerid ", int " flags ,
.BI "                  const struct itimerspec *" new_value ,
.BI "                  struct itimerspec * " old_value );
.BI "int timer_gettime(timer_t " timerid ", struct itimerspec *" curr_value );
.fi

Link with
.IR \-lrt .
.sp
.in -4n
Feature Test Macro Requirements for glibc (see
.BR feature_test_macros (7)):
.in
.sp
.BR timer_settime (),
.BR timer_gettime ():
_POSIX_C_SOURCE >= 199309
.SH DESCRIPTION
.BR timer_settime ()
arms or disarms the timer identified by
.IR timerid .
The
.I new_value
argument is an
.I itimerspec
structure that specifies the new initial value and
the new interval for the timer.
The
.I itimerspec
structure is defined as follows:

.in +4n
.nf
struct timespec {
    time_t tv_sec;                /* Seconds */
    long   tv_nsec;               /* Nanoseconds */
};

struct itimerspec {
    struct timespec it_interval;  /* Timer interval */
    struct timespec it_value;     /* Initial expiration */
};
.fi
.in

Each of the substructures of the
.I itimerspec
structure is a
.I timespec
structure that allows a time value to be specified
in seconds and nanoseconds.
These time values are measured according to the clock
that was specified when the timer was created by
.BR timer_create ()

If
.I new_value->it_value
specifies a non-zero value (i.e., either subfield is non-zero), then
.BR timer_settime ()
arms (starts) the timer,
setting it to initially expire at the given time.
(If the timer was already armed,
then the previous settings are overwritten.)
If
.I new_value->it_value
specifies a zero value
(i.e., both subfields are zero),
then the timer is disarmed.

The
.I new_value->it_interval
field specifies the period of the timer, in seconds and nanoseconds.
If this field is non-zero, then each time that an armed timer expires,
the timer is reloaded from the value specified in
.IR new_value->it_interval .
If
.I new_value->it_interval
specifies a zero value
then the timer expires just once, at the time specified by
.IR it_value .

By default, the initial expiration time specified in
.I new_value->it_value
is interpreted relative to the current time on the timer's
clock at the time of the call.
This can be modified by specifying
.B TIMER_ABSTIME
in
.IR flags ,
in which case
.I new_value->it_value
is interpreted as an absolute value as measured on the timer's clock;
that is, the timer will expire when the clock value reaches the
value specified by
.IR new_value->it_value .
If the specified absolute time has already passed,
then the timer expires immediately,
and the overrun count (see
.BR timer_getoverrun (2))
will be set correctly.
.\" By experiment: the overrun count is set correctly, for CLOCK_REALTIME.

If the value of the
.B CLOCK_REALTIME
clock is adjusted while an absolute timer based on that clock is armed,
then the expiration of the timer will be appropriately adjusted.
Adjustments to the
.B CLOCK_REALTIME
clock have no effect on relative timers based on that clock.
.\" Similar remarks might apply with respect to process and thread CPU time
.\" clocks, but these clocks are not currently (2.6.28) settable on Linux.

If
.I old_value
is not NULL, then it returns the previous interval of the timer (in
.IR old_value->it_interval )
and the amount of time until the timer
would previously have next expired (in
.IR old_value->it_value ).

.BR timer_gettime ()
returns the time until next expiration, and the the interval,
for the timer specified by
.IR timerid ,
in the buffer pointed to by
.IR curr_value .
The time remaining until the next timer expiration is returned in
.IR curr_value.it_value ;
this is always a relative value, regardless of whether the
.BR TIMER_ABSTIME
flag was used when arming the timer.
If the value returned in
.IR curr_value.it_value
is zero, then the timer is currently disarmed.
The timer interval is returned in
.IR curr_value.it_interval .
If the value returned in
.IR curr_value.it_interval
is zero, then this is a "one-shot" timer.
.SH RETURN VALUE
On success,
.BR timer_settime ()
and
.BR timer_gettime ()
return 0.
On error, \-1 is returned, and
.I errno
is set to indicate the error.
.SH ERRORS
These functions may fail with the following errors:
.TP
.B EFAULT
.IR new_value ,
.IR old_value ,
or
.I curr_value
is not valid a pointer.
.TP
.B EINVAL
.I timerid
is invalid.
.\" FIXME . eventually: invalid value in flags
.PP
.BR timer_settime ()
may fail with the following errors:
.TP
.B EINVAL
.I new_value.it_value
is negative; or
.I new_value.it_value.tv_nsec
is negative or greater than 999,999,999.
.SH VERSIONS
These system calls are available since Linux 2.6.
.SH CONFORMING TO
POSIX.1-2001
.SH SEE ALSO
.BR timer_create (2),
.BR timer_settime (2),
.BR timer_getoverrun (2),
.BR time (7)
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: timer_settime.2

[Peter Zijlstra]

On Tue, 2009-02-10 at 14:54 +1300, Michael Kerrisk wrote:
>        If the value of the CLOCK_REALTIME clock is adjusted  while  an
>        absolute  timer  based on that clock is armed, then the expira-
>        tion of the timer will be appropriately adjusted.   Adjustments
>        to  the  CLOCK_REALTIME clock have no effect on relative timers
>        based on that clock.

I cannot find this to be true.

>From what I can make of the code, clock_settime() ends up calling
do_sys_settimeofday() for CLOCK_REALTIME (and the other clocks).

It is, however, not treating relative/abs timers any differently.

Both get converted to an absolute expiration time when set.

If POSIX mandates that we keep relative timers unchanged when we change
the underlying clock, we'd have to iterate all pending timers and reset
them.



--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: timer_settime.2

[Michael Kerrisk]

Hi Peter,

Peter Zijlstra wrote:
> On Tue, 2009-02-10 at 14:54 +1300, Michael Kerrisk wrote:
>>        If the value of the CLOCK_REALTIME clock is adjusted  while  an
>>        absolute  timer  based on that clock is armed, then the expira-
>>        tion of the timer will be appropriately adjusted.   Adjustments
>>        to  the  CLOCK_REALTIME clock have no effect on relative timers
>>        based on that clock.
> 
> I cannot find this to be true.
> 
>>From what I can make of the code, clock_settime() ends up calling
> do_sys_settimeofday() for CLOCK_REALTIME (and the other clocks).
> 
> It is, however, not treating relative/abs timers any differently.
> 
> Both get converted to an absolute expiration time when set.
> 
> If POSIX mandates that we keep relative timers unchanged when we change
> the underlying clock, we'd have to iterate all pending timers and reset
> them.

The rules do indeed come from POSIX.

And indeed the rules do seem to be followed on Linux.  Since I found
parts of the code to be hard to track, I also checked things with an
example program.  (Ahhh! the pitfalls of reading code to find the
truth!)

Pull out your watch and time what happens with these two runs of my
test program below:

$ sudo ./ptmr_demo r - 10 5
$ sudo ./ptmr_demo r a 10 5

Cheers,

Michael

/*#* ptmr_demo.c

   Compile on Linux with -lrt
*/
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <errno.h>
#include <time.h>
#include <pthread.h>

#define SIG SIGUSR1

#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                        } while (0)

static void
print_siginfo(siginfo_t *si)
{
    timer_t *tidp;
    int or;

    tidp = si->si_value.sival_ptr;

    printf("    sival_ptr = %p; ", si->si_value.sival_ptr);
    printf("    *sival_ptr = 0x%lx\n", (long) *tidp);

    or = timer_getoverrun(*tidp);
    if (or == -1)
        errExit("timer_getoverrun");
    else
        printf("    overrun count = %d\n", or);
}

static void
handler(int sig, siginfo_t *si, void *uc)
{
    printf("Caught signal %d\n", sig);
    print_siginfo(si);

    exit(EXIT_SUCCESS);
}

static void *
thread_func(void *arg)
{
    printf("Thread burning CPU\n");
    for (;;)
        ;
}

int
main(int argc, char *argv[])
{
    timer_t timer_id;
    struct sigevent sev;
    struct itimerspec its;
    struct sigaction sa;
    clockid_t clock_id;
    int flags;
    struct timespec ts;

    if (argc < 4) {
        fprintf(stderr, "Usage: %s <clockid> <flags> <num-secs> "
                "[<clock-adj-secs>]\n", argv[0]);
#define fpe(str) fprintf(stderr, str);
        fpe("<clockid> is one of:\n");
        fpe("\tm  CLOCK_MONOTONIC\n");
        fpe("\tr  CLOCK_REALTIME\n");
        fpe("\tp  CLOCK_PROCESS_CPUTIME_ID\n");
        fpe("\tt  CLOCK_THREAD_CPUTIME_ID\n");
        fpe("\tC  clock of a child process that burns CPU time\n");
        fpe("\tT  clock of a sub-thread that burns CPU time\n");
        fpe("<flags> is one of:\n");
        fpe("\ta  absolute timer (<num-secs> is added to current\n");
        fpe("\t   clock value)\n")
        fpe("\t-  relative timer\n")
        fpe("<num-secs> is the initial expiration time for the timer\n");
        fpe("<clock-adj-secs> is number of seconds by which clock\n");
        fpe("\tshould be adjusted (clock_settime()) after timer\n");
        fpe("\thas started\n")
        exit(EXIT_FAILURE);
    }

    printf("Establishing handler for signal %d\n", SIG);
    sa.sa_flags = SA_SIGINFO;
    sa.sa_sigaction = handler;
    sigemptyset(&sa.sa_mask);
    if (sigaction(SIG, &sa, NULL) == -1)
        errExit("sigaction");

    if (argv[1][0] == 'C') {
        pid_t cpid;

        cpid = fork();
        if (cpid == -1)
            errExit("fork");
        if (cpid == 0) {
            usleep(10000);
            printf("Child process burning CPU time\n");
            alarm(100); /* Ensure child eventually dies */
            for (;;)
                ;
        } else {        /* Parent gets CPU clock ID of child and
                           falls through */
            if (clock_getcpuclockid(cpid, &clock_id) == -1)
                errExit("clock_getcpuclockid");
        }

    } else if (argv[1][0] == 'T') {
        pthread_t t;

        errno = pthread_create(&t, NULL, thread_func, NULL);
        if (errno != 0)
            errExit("pthread_create");
        errno = pthread_getcpuclockid(t, &clock_id);
        if (errno != 0)
            errExit("pthread_getcpuclockid");

    } else {
        clock_id = (argv[1][0] == 'm') ? CLOCK_MONOTONIC :
                   (argv[1][0] == 'p') ? CLOCK_PROCESS_CPUTIME_ID :
                   (argv[1][0] == 't') ? CLOCK_THREAD_CPUTIME_ID :
                   (argv[1][0] == 'r') ? CLOCK_REALTIME :
                   -999999;     /* Unlikely to be a valid clock ID */
    }

    sev.sigev_notify = SIGEV_SIGNAL;
    sev.sigev_signo = SIG;
    sev.sigev_value.sival_ptr = &timer_id;
    if (timer_create(clock_id, &sev, &timer_id) == -1)
        errExit("timer_create");

    printf("clock ID is 0x%lx\n", (long) clock_id);
    printf("timer ID is 0x%lx\n", (long) timer_id);

    flags = (argv[2][0] == 'a') ? TIMER_ABSTIME : 0;

    if (flags & TIMER_ABSTIME) {
        printf("Absolute timer\n");
        if (clock_gettime(clock_id, &ts) == -1)
            errExit("clock_gettime");
        printf("Current clock value = %ld\n", (long) ts.tv_sec);
        its.it_value.tv_sec = ts.tv_sec + atoi(argv[3]);
        its.it_value.tv_nsec = ts.tv_nsec;
    } else {
        its.it_value.tv_sec = atoi(argv[3]);
        its.it_value.tv_nsec = 0;
    }

    its.it_interval.tv_sec = 1;
    its.it_interval.tv_nsec = 0;

    printf("its.it_value.tv_sec = %ld\n",
            (long) its.it_value.tv_sec);

    if (timer_settime(timer_id, flags, &its, NULL) == -1)
         errExit("timer_settime");

    if (argc > 4) {
        if (clock_gettime(clock_id, &ts) == -1)
            errExit("clock_gettime");
        ts.tv_sec += atoi(argv[4]);
        printf("About to adjust clock to %ld\n", (long) ts.tv_sec);
        if (clock_settime(clock_id, &ts) == -1)
            errExit("clock_settime");
    }

    if (clock_id == CLOCK_PROCESS_CPUTIME_ID ||
            clock_id == CLOCK_THREAD_CPUTIME_ID) {
        printf("main() burning CPU\n");
        printf("About to enter infinite loop\n");
        for (;;)
            getppid();
    } else {
        printf("main() pausing\n");
        pause();
    }
}
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: timer_settime.2

[Peter Zijlstra]

On Thu, 2009-02-12 at 08:17 +1300, Michael Kerrisk wrote:
> Hi Peter,
> 
> Peter Zijlstra wrote:
> > On Tue, 2009-02-10 at 14:54 +1300, Michael Kerrisk wrote:
> >>        If the value of the CLOCK_REALTIME clock is adjusted  while  an
> >>        absolute  timer  based on that clock is armed, then the expira-
> >>        tion of the timer will be appropriately adjusted.   Adjustments
> >>        to  the  CLOCK_REALTIME clock have no effect on relative timers
> >>        based on that clock.
> > 
> > I cannot find this to be true.
> > 
> >>From what I can make of the code, clock_settime() ends up calling
> > do_sys_settimeofday() for CLOCK_REALTIME (and the other clocks).
> > 
> > It is, however, not treating relative/abs timers any differently.
> > 
> > Both get converted to an absolute expiration time when set.
> > 
> > If POSIX mandates that we keep relative timers unchanged when we change
> > the underlying clock, we'd have to iterate all pending timers and reset
> > them.
> 
> The rules do indeed come from POSIX.
> 
> And indeed the rules do seem to be followed on Linux.  Since I found
> parts of the code to be hard to track, I also checked things with an
> example program.  (Ahhh! the pitfalls of reading code to find the
> truth!)

Ah, quite so. The magic is in hrtimers. Relative timers are ran on clock
monotonic.

OK I think that was the last bit.

Feel free to add:

Reviewed-by: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>

To all 4 pathces.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: timer_settime.2

[Thomas Gleixner]

On Sat, 14 Feb 2009, Peter Zijlstra wrote:
> On Thu, 2009-02-12 at 08:17 +1300, Michael Kerrisk wrote:
> > Hi Peter,
> > 
> > Peter Zijlstra wrote:
> > > On Tue, 2009-02-10 at 14:54 +1300, Michael Kerrisk wrote:
> > >>        If the value of the CLOCK_REALTIME clock is adjusted  while  an
> > >>        absolute  timer  based on that clock is armed, then the expira-
> > >>        tion of the timer will be appropriately adjusted.   Adjustments
> > >>        to  the  CLOCK_REALTIME clock have no effect on relative timers
> > >>        based on that clock.
> > > 
> > > I cannot find this to be true.
> > > 
> > >>From what I can make of the code, clock_settime() ends up calling
> > > do_sys_settimeofday() for CLOCK_REALTIME (and the other clocks).
> > > 
> > > It is, however, not treating relative/abs timers any differently.
> > > 
> > > Both get converted to an absolute expiration time when set.
> > > 
> > > If POSIX mandates that we keep relative timers unchanged when we change
> > > the underlying clock, we'd have to iterate all pending timers and reset
> > > them.
> > 
> > The rules do indeed come from POSIX.
> > 
> > And indeed the rules do seem to be followed on Linux.  Since I found
> > parts of the code to be hard to track, I also checked things with an
> > example program.  (Ahhh! the pitfalls of reading code to find the
> > truth!)
> 
> Ah, quite so. The magic is in hrtimers. Relative timers are ran on clock
> monotonic.

Yes. I tripped over the relative CLOCK_REALTIME timer not being
affected of clock modifications in the early days of hrtimers. The
solution was just to run those timers on CLOCK_MONOTONIC to avoid any
special treatment.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: timer_settime.2

[Michael Kerrisk]

Hi Peter,

On 2/15/09, Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org> wrote:
> On Thu, 2009-02-12 at 08:17 +1300, Michael Kerrisk wrote:
>> Hi Peter,
>>
>> Peter Zijlstra wrote:
>> > On Tue, 2009-02-10 at 14:54 +1300, Michael Kerrisk wrote:
>> >>        If the value of the CLOCK_REALTIME clock is adjusted  while  an
>> >>        absolute  timer  based on that clock is armed, then the expira-
>> >>        tion of the timer will be appropriately adjusted.   Adjustments
>> >>        to  the  CLOCK_REALTIME clock have no effect on relative timers
>> >>        based on that clock.
>> >
>> > I cannot find this to be true.
>> >
>> >>From what I can make of the code, clock_settime() ends up calling
>> > do_sys_settimeofday() for CLOCK_REALTIME (and the other clocks).
>> >
>> > It is, however, not treating relative/abs timers any differently.
>> >
>> > Both get converted to an absolute expiration time when set.
>> >
>> > If POSIX mandates that we keep relative timers unchanged when we change
>> > the underlying clock, we'd have to iterate all pending timers and reset
>> > them.
>>
>> The rules do indeed come from POSIX.
>>
>> And indeed the rules do seem to be followed on Linux.  Since I found
>> parts of the code to be hard to track, I also checked things with an
>> example program.  (Ahhh! the pitfalls of reading code to find the
>> truth!)
>
> Ah, quite so. The magic is in hrtimers. Relative timers are ran on clock
> monotonic.
>
> OK I think that was the last bit.
>
> Feel free to add:
>
> Reviewed-by: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>
>
> To all 4 pathces.

Done.  Thanks for looking the pages over.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html