Re: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org>]

On Thu, Sep 05, 2013 at 01:03:48PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Rodrigo, (and Christoph and Peter, you may want to look at the
> man-page patch below)
> 
> On Thu, Sep 5, 2013 at 10:10 AM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
> > On Wed, Sep 04, 2013 at 04:47:25PM +0000, Christoph Lameter wrote:
> >> On Wed, 4 Sep 2013, Rodrigo Campos wrote:
> >>
> >> > On Wed, Sep 04, 2013 at 04:01:27PM +0000, Christoph Lameter wrote:
> >> > > On Wed, 4 Sep 2013, Michael Kerrisk (man-pages) wrote:
> >> > >
> >> > > > > I don't know. But looking at the git repo, it seems in the first git commit
> >> > > > > (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) it was already safe,
> >> > >
> >> > > What do you mean by "safe"? Note that the manpage was written mainly based
> >> >
> >> > That you don't get bogus results on SMP systems. Now, it I think the note is
> >> > obsolete (Peter confirmed that in fact it is), but we want to know when the note
> >> > become obsolete.
> >>
> >> Well as soon as you have a kernel implementation of these clocks the issue
> >> should be moot.
> >
> > Ohh, so my "theory" was right. Thanks a lot for the insight :-)
> >
> > So, Michael, IIUC what Christoph says, the note on SMP systems was relevant when
> > glibc provide simple wrappers (like to retrieve TSC/ITC register contents) and
> > didn't use the kernel support for it (or kernel support was not there).
> 
> Yup, that's my take on it too.

:-)


> > Checking the glibc repo, I *think* the commit that starts using the kernel for
> > these clocks might be this one: 2f4f3bd4a9ad805383b278e5b975971ca15c7a77
> > ("Handle CLOCK_PROCESS_CPUTIME_ID and CLOCK_PROCESS_THREAD_ID specially,
> > translating to the kernel clockid_t for our own process/thread clock.")
> >
> > That commit, doing a simple:
> >         git tag --contains 2f4f3bd | sort -V
> >
> > seems to be included in glibc-2.4 for the first time, released on 6/Mar/2006.
> > But, of course, I'm not sure this is the right commit :-)
> 
> I'm not sure if it's the right commit, but looking at source trees,
> your estimate of glibc-2.4 looks right to me.

Great



> > If that is the case, should we change the note to say since which glibc (do we
> > care about any other libc?) and kernel version these are safe on SMP and keep
> > the note for people using olders version ?
> 
> Exactly. See below.
> 
> > Also, I didn't check if kernel support was backported to Linux 2.4...
> 
> 2.4.x doesn't have the two CPUTIME clocks.

Thanks, I didn't know that :-)

> 
> How does the patch below look to you?

Looks good, thanks! But I it failed to apply here as it is. And a minor question
below

> 
> Cheers,
> 
> Michael
> 
> --- a/man2/clock_getres.2
> +++ b/man2/clock_getres.2
> @@ -221,12 +221,13 @@ are available.
>  (See also
>  .BR sysconf (3).)
>  .SH NOTES
> -.SS Note for SMP systems
> -The
> +.SS Historical note for SMP systems
> +Before Linux added kernel support for
>  .B CLOCK_PROCESS_CPUTIME_ID
>  and
> -.B CLOCK_THREAD_CPUTIME_ID
> -clocks are realized on many platforms using timers from the CPUs
> +.BR CLOCK_THREAD_CPUTIME_ID ,
> +glibc implemented these clocks on many platforms using timer
> +registers from the CPUs
>  (TSC on i386, AR.ITC on Itanium).
>  These registers may differ between CPUs and as a consequence
>  these clocks may return
> @@ -252,6 +253,15 @@ Glibc contains no provisions to deal with these
> offsets (unlike the Linux
>  Kernel).
>  Typically these offsets are small and therefore the effects may be
>  negligible in most cases.
> +
> +Since glibc 2.4,

Is the new line here on purpose ?

> +the wrapper functions for the system calls described in this page avoid
> +the abovementioned problems by employing the kernel implementation of
> +.B CLOCK_PROCESS_CPUTIME_ID
> +and
> +.BR CLOCK_THREAD_CPUTIME_ID ,
> +on systems that provide such an implementation

And here too ?

> +(i.e., Linux 2.6.12 and later).
>  .SH BUGS
>  According to POSIX.1-2001, a process with "appropriate privileges" may set the
>  .B CLOCK_PROCESS_CPUTIME_ID





Thanks a lot,
Rodrigo
--
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