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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
