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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux