clock_getres.2: Remove obsolete note on SMP systems

clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

Hi,

About a month and some weeks ago I opened a bug asking if the note on SMP
systems on clock_gettime() manpage was outdated. I explained why I think it
might be outdated and then continue playing with it, until I was even more sure
that it was outdated. Then I found Peter Ziljstra on IRC and he confirmed it is
in fact outdated (no doubts now :-))

The bugzilla entry is here: https://bugzilla.kernel.org/show_bug.cgi?id=60602

So on the next day I uploaded a patch to the bug saying this (the same I'm
sending now) and got no answer. I did ping a couple of times (like 3) but no
answer.

I initially opened the bug on the bugzilla because I didn't have a patch, it was
just a question (I understand that this is the preferred way, from
https://www.kernel.org/doc/man-pages/reporting_bugs.html but I'm not sure if I'm
missunderstanding something). And then, when I had a patch for it, just uploaded
there... seemed natural to me.

So, now I'm sending the patch here because: a) now I have a patch :-D, b) maybe it
has more attention than bugzilla auto-emails ?. But sorry in advance if I should
not send it here if it's already on the bugzilla.

Any comments are, of course, welcome. And if there is something else I should
try/fix, please let me know. I've checked that the page looks fine after the
removal locally, but I might be missing something else :-)


Also, please keep me in Cc: since I'm not subscribed





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

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

[Rodrigo Campos]

As confirmed by peterz on IRC, this note is obsolete:

	<peterz> rata: that section is obsolete; CLOCK_THREAD_CPUTIME_ID is good
	<peterz> rata: CLOCK_PROCESS_CPUTIME_ID is also correct

So this patch just removes it.
---
 man2/clock_getres.2 |   32 --------------------------------
 1 file changed, 32 deletions(-)

diff --git a/man2/clock_getres.2 b/man2/clock_getres.2
index 10ecd18..eac97cd 100644
--- a/man2/clock_getres.2
+++ b/man2/clock_getres.2
@@ -218,38 +218,6 @@ indicate that
 are available.
 (See also
 .BR sysconf (3).)
-.SH NOTES
-.SS Note for SMP systems
-The
-.B CLOCK_PROCESS_CPUTIME_ID
-and
-.B CLOCK_THREAD_CPUTIME_ID
-clocks are realized on many platforms using timers from the CPUs
-(TSC on i386, AR.ITC on Itanium).
-These registers may differ between CPUs and as a consequence
-these clocks may return
-.B bogus results
-if a process is migrated to another CPU.
-.PP
-If the CPUs in an SMP system have different clock sources then
-there is no way to maintain a correlation between the timer registers since
-each CPU will run at a slightly different frequency.
-If that is the case then
-.I clock_getcpuclockid(0)
-will return
-.B ENOENT
-to signify this condition.
-The two clocks will then be useful only if it
-can be ensured that a process stays on a certain CPU.
-.PP
-The processors in an SMP system do not start all at exactly the same
-time and therefore the timer registers are typically running at an offset.
-Some architectures include code that attempts to limit these offsets on bootup.
-However, the code cannot guarantee to accurately tune the offsets.
-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.
 .SH BUGS
 According to POSIX.1-2001, a process with "appropriate privileges" may set the
 .B CLOCK_PROCESS_CPUTIME_ID
-- 
1.7.10.4

--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Michael Kerrisk (man-pages)]

Hi Rodrigo,

On Tue, Sep 3, 2013 at 12:05 PM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
> As confirmed by peterz on IRC, this note is obsolete:
>
>         <peterz> rata: that section is obsolete; CLOCK_THREAD_CPUTIME_ID is good
>         <peterz> rata: CLOCK_PROCESS_CPUTIME_ID is also correct
>
> So this patch just removes it.

Clearly, the page needs amending. However, ideal would be to describe
*when* the section became obsolete (which kernel version). Do you or
Peter know, or have an idea how we can determine that information?

Cheers,

Michael


> ---
>  man2/clock_getres.2 |   32 --------------------------------
>  1 file changed, 32 deletions(-)
>
> diff --git a/man2/clock_getres.2 b/man2/clock_getres.2
> index 10ecd18..eac97cd 100644
> --- a/man2/clock_getres.2
> +++ b/man2/clock_getres.2
> @@ -218,38 +218,6 @@ indicate that
>  are available.
>  (See also
>  .BR sysconf (3).)
> -.SH NOTES
> -.SS Note for SMP systems
> -The
> -.B CLOCK_PROCESS_CPUTIME_ID
> -and
> -.B CLOCK_THREAD_CPUTIME_ID
> -clocks are realized on many platforms using timers from the CPUs
> -(TSC on i386, AR.ITC on Itanium).
> -These registers may differ between CPUs and as a consequence
> -these clocks may return
> -.B bogus results
> -if a process is migrated to another CPU.
> -.PP
> -If the CPUs in an SMP system have different clock sources then
> -there is no way to maintain a correlation between the timer registers since
> -each CPU will run at a slightly different frequency.
> -If that is the case then
> -.I clock_getcpuclockid(0)
> -will return
> -.B ENOENT
> -to signify this condition.
> -The two clocks will then be useful only if it
> -can be ensured that a process stays on a certain CPU.
> -.PP
> -The processors in an SMP system do not start all at exactly the same
> -time and therefore the timer registers are typically running at an offset.
> -Some architectures include code that attempts to limit these offsets on bootup.
> -However, the code cannot guarantee to accurately tune the offsets.
> -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.
>  .SH BUGS
>  According to POSIX.1-2001, a process with "appropriate privileges" may set the
>  .B CLOCK_PROCESS_CPUTIME_ID
> --
> 1.7.10.4
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

On Wed, Sep 04, 2013 at 02:32:49PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Rodrigo,
> 
> On Tue, Sep 3, 2013 at 12:05 PM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
> > As confirmed by peterz on IRC, this note is obsolete:
> >
> >         <peterz> rata: that section is obsolete; CLOCK_THREAD_CPUTIME_ID is good
> >         <peterz> rata: CLOCK_PROCESS_CPUTIME_ID is also correct
> >
> > So this patch just removes it.
> 
> Clearly, the page needs amending. However, ideal would be to describe
> *when* the section became obsolete (which kernel version). Do you or
> Peter know, or have an idea how we can determine that information?

I don't know. But looking at the git repo, it seems in the first git commit
(1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) it was already safe, because
in kernel/posix-cpu-timers.c cpu_clock_sample() uses the scheduler to get the
value. And the basic pattern:

	posix_cpu_clock_get() --> posix_cpu_clock_get() --> cpu_clock_sample()

(for the case of CLOCK_THREAD_CPUTIME_ID) seems unchanged. So, if I guess it was
safe on those days too.

And for CLOCK_PROCESS_CPUTIME_ID, something similar happens if I follow the code
correctly. The call chain I see is:

	process_cpu_clock_get() --> posix_cpu_clock_get() -->
	cpu_clock_sample_group() --> cpu_clock_sample_group_locked()

And if I follow the clock macros correctly, ends up calling
cpu_clock_sample_group_locked() with CPUCLOCK_SCHED, which calls the scheduler
and I *expect* that to be safe too.

But I would **really** like if Peter can confirm this, as I really don't know :-)



Btw, if in the first git commit it was safe, should I try to look to the history
before it ?




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

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

[Michael Kerrisk (man-pages)]

[CC=+Christoph Lameter, since it looks likes he wrote that text in the
man page, and I hope he might be able to offer some insight.]

Christoph, the text we're talking about is the "Note for SMP systems"
that you wrote for the clock_getres() man page, back around 2004.:

   Note for SMP systems
       The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID
       clocks are realized on many platforms using timers  from
       the CPUs (TSC on i386, AR.ITC on Itanium).  These regis‐
       ters may differ between CPUs and as a consequence  these
       clocks may return bogus results if a process is migrated
       to another CPU.

       If the CPUs  in  an  SMP  system  have  different  clock
       sources  then  there is no way to maintain a correlation
       between the timer registers since each CPU will run at a
       slightly  different frequency.  If that is the case then
       clock_getcpuclockid(0) will  return  ENOENT  to  signify
       this condition.  The two clocks will then be useful only
       if it can be ensured that a process stays on  a  certain
       CPU.

       The  processors  in  an  SMP  system do not start all at
       exactly the same time and therefore the timer  registers
       are  typically running at an offset.  Some architectures
       include code that attempts to  limit  these  offsets  on
       bootup.   However,  the  code  cannot guarantee to accu‐
       rately tune the offsets.  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.

On Wed, Sep 4, 2013 at 3:32 PM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
> On Wed, Sep 04, 2013 at 02:32:49PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Rodrigo,
>>
>> On Tue, Sep 3, 2013 at 12:05 PM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
>> > As confirmed by peterz on IRC, this note is obsolete:
>> >
>> >         <peterz> rata: that section is obsolete; CLOCK_THREAD_CPUTIME_ID is good
>> >         <peterz> rata: CLOCK_PROCESS_CPUTIME_ID is also correct
>> >
>> > So this patch just removes it.
>>
>> Clearly, the page needs amending. However, ideal would be to describe
>> *when* the section became obsolete (which kernel version). Do you or
>> Peter know, or have an idea how we can determine that information?
>
> I don't know. But looking at the git repo, it seems in the first git commit
> (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) it was already safe,

So, some history: CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
first appeared in 2.6.12, as far as I know.

Your suggesting that these clocks were safe in 2.6.12-rc2 (April
2005). At this point, I'm confused. AFAICT, Christoph wrote his text
in mid-2004, quite some time before 2.61.12 was released with the
initial CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
implementations. The thing is, Christoph, is usually pretty sharp, so
I assume that he was talking about something that was true at some
point, but it's unclear to me when that point could have been, since
the timelines don't seem to match up (unless, of course, your
suppositions are wrong, Rodrigo, but I'm not assuming that at this
point).

> in kernel/posix-cpu-timers.c cpu_clock_sample() uses the scheduler to get the
> value. And the basic pattern:
>
>         posix_cpu_clock_get() --> posix_cpu_clock_get() --> cpu_clock_sample()
>
> (for the case of CLOCK_THREAD_CPUTIME_ID) seems unchanged. So, if I guess it was
> safe on those days too.
>
> And for CLOCK_PROCESS_CPUTIME_ID, something similar happens if I follow the code
> correctly. The call chain I see is:
>
>         process_cpu_clock_get() --> posix_cpu_clock_get() -->
>         cpu_clock_sample_group() --> cpu_clock_sample_group_locked()
>
> And if I follow the clock macros correctly, ends up calling
> cpu_clock_sample_group_locked() with CPUCLOCK_SCHED, which calls the scheduler
> and I *expect* that to be safe too.
>
> But I would **really** like if Peter can confirm this, as I really don't know :-)
>
>
>
> Btw, if in the first git commit it was safe, should I try to look to the history
> before it ?

Let's see is Christoph or Peter has something to say.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

On Wed, Sep 04, 2013 at 05:01:26PM +0200, Michael Kerrisk (man-pages) wrote:
> >>
> >> Clearly, the page needs amending. However, ideal would be to describe
> >> *when* the section became obsolete (which kernel version). Do you or
> >> Peter know, or have an idea how we can determine that information?
> >
> > I don't know. But looking at the git repo, it seems in the first git commit
> > (1da177e4c3f41524e886b7f1b8a0c1fc7321cac2) it was already safe,
> 
> So, some history: CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
> first appeared in 2.6.12, as far as I know.
> 
> Your suggesting that these clocks were safe in 2.6.12-rc2 (April
> 2005). At this point, I'm confused. AFAICT, Christoph wrote his text

Ohh, I didn't know that. Now I'm confused too :S

> in mid-2004, quite some time before 2.61.12 was released with the
> initial CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
> implementations. The thing is, Christoph, is usually pretty sharp, so
> I assume that he was talking about something that was true at some
> point, but it's unclear to me when that point could have been, since
> the timelines don't seem to match up (unless, of course, your
> suppositions are wrong, Rodrigo, but I'm not assuming that at this
> point).

Hmmm, but chances are that I'm wrong I think... =)


> 
> Let's see is Christoph or Peter has something to say.

Let's see :)






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

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

[Christoph Lameter]

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
on my experience on IA64 with ITC registers. There were numerous bugs in
2004/2005 due to glibc / kernel / firmware issues.

> So, some history: CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
> first appeared in 2.6.12, as far as I know.

Those were earlier supported by glibc before kernel support was added. At
some point they were used in some weird scheme to retrieve TSC/ITC
register contents.

> point, but it's unclear to me when that point could have been, since
> the timelines don't seem to match up (unless, of course, your
> suppositions are wrong, Rodrigo, but I'm not assuming that at this
> point).

Only have a vague recollection of these things at this point and I have
no longer access to my email from that time period since I am no longer
with SGI.
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

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.





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

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

[Christoph Lameter]

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.

--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

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

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

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 ?

Also, I didn't check if kernel support was backported to Linux 2.4...





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

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

[Michael Kerrisk (man-pages)]

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.

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

How does the patch below look to you?

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,
+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
+(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


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

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

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

[Michael Kerrisk (man-pages)]

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

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

It makes no difference to the output; I often break long source lines
at punctuation points.

Thanks for all your help getting to the final result, Rodrigo.

Cheers,

Michael
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

On Fri, Sep 06, 2013 at 06:11:03AM +0200, Michael Kerrisk (man-pages) wrote:
> >>  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 ?
> 
> It makes no difference to the output; I often break long source lines
> at punctuation points.

Ohh, okay. Wanted to make sure it was on purpose :-)

> 
> Thanks for all your help getting to the final result, Rodrigo.

Thank you :-)
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Christoph Lameter]

On Thu, 5 Sep 2013, Rodrigo Campos wrote:

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

Right. Some older glibc versions will always handle these clock request in
user space. Old RH4 and certain old SUSE versions were some of the main
issues.

--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Rodrigo Campos]

On Thu, Sep 05, 2013 at 02:22:09PM +0000, Christoph Lameter wrote:
> On Thu, 5 Sep 2013, Rodrigo Campos wrote:
> 
> > 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 ?
> 
> Right. Some older glibc versions will always handle these clock request in
> user space. Old RH4 and certain old SUSE versions were some of the main
> issues.


Great, thanks a lot for all the info :-)
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Michael Kerrisk (man-pages)]

On Wed, Sep 4, 2013 at 6:01 PM, Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org> 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
> on my experience on IA64 with ITC registers. There were numerous bugs in
> 2004/2005 due to glibc / kernel / firmware issues.
>
>> So, some history: CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID
>> first appeared in 2.6.12, as far as I know.
>
> Those were earlier supported by glibc before kernel support was added.

Ahhh -- that was a point I'd forgotten. That makes a lot of pieces
fall into place ;-).

> At
> some point they were used in some weird scheme to retrieve TSC/ITC
> register contents.
>
>> point, but it's unclear to me when that point could have been, since
>> the timelines don't seem to match up (unless, of course, your
>> suppositions are wrong, Rodrigo, but I'm not assuming that at this
>> point).
>
> Only have a vague recollection of these things at this point and I have
> no longer access to my email from that time period since I am no longer
> with SGI.

I think your point above is enough for me and Rodrigo to sort it now.

Thanks, Christoph.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
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: [PATCH] clock_getres.2: Remove obsolete note on SMP systems

[Peter Zijlstra]

On Wed, Sep 04, 2013 at 02:32:49PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Rodrigo,
> 
> On Tue, Sep 3, 2013 at 12:05 PM, Rodrigo Campos <rodrigo-aOqSs0FX/Gu4Tu3zPC53fQ@public.gmane.org> wrote:
> > As confirmed by peterz on IRC, this note is obsolete:
> >
> >         <peterz> rata: that section is obsolete; CLOCK_THREAD_CPUTIME_ID is good
> >         <peterz> rata: CLOCK_PROCESS_CPUTIME_ID is also correct
> >
> > So this patch just removes it.
> 
> Clearly, the page needs amending. However, ideal would be to describe
> *when* the section became obsolete (which kernel version). Do you or
> Peter know, or have an idea how we can determine that information?

I was out on holidays but it seems you guys sorted the issue -- glibc
userspace handling of the clocks.

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