Messages in this thread | | | Subject | Re: [RFC 0/2] ABI for clock_gettime_ns | From | john stultz <> | Date | Wed, 14 Dec 2011 11:07:46 -0800 |
| |
On Wed, 2011-12-14 at 19:30 +0100, Richard Cochran wrote: > On Wed, Dec 14, 2011 at 08:48:30AM -0800, john stultz wrote: > > On Wed, 2011-12-14 at 08:46 +0100, Richard Cochran wrote: > > > On Mon, Dec 12, 2011 at 11:09:29PM -0800, Andy Lutomirski wrote: > > > > On Mon, Dec 12, 2011 at 7:43 PM, john stultz <johnstul@us.ibm.com> wrote: > > > > >> - New name, to distance ourselves from POSIX (clock_ns_get?) > > > > > > > > I will defer to the bikeshedding consensus :) > > > > > > > > >> - Family of calls, with set/get > > > > > > > > Setting the time is a big can of worms. adjtimex is rather > > > > incomprehensible (without reading lots of source and/or the rfc) and > > > > IMO puts a lot of NTP magic into the kernel, where it doesn't belong. > > > > Honestly, I don't really see how we jumped to adjtimex from setting the > > time, nor the complexity hinted at. First, the rational for getting > > clock_gettime_ns is to avoid the overhead of userland translating from > > timespec to ns. I doubt there are similar performance needs for > > settimeofday(). Even if it was needed, it shouldn't be more complex > > then the unit conversion done in this abi patch. Am I missing something? > > So, you agree on adding new syscalls as a performance tweek?
Well, the patch that started this off was introducing a new vdso function (which had no syscall equivalent) that provided the same data as clock_gettime(CLOCK_THREAD_CPUTIME,...) but in ns format, because that was a reasonable performance win.
While I'm not eager to add duplicative interfaces, if the syscall data structure is in the way of performance, folks will make ugly hacks to get around it, so we might as well adapt to something better as a standard interface. However, to avoid maintenance burden, I'd like to keep the duplicative interfaces similar so we can share as much back-end logic as possible.
> I am not against it, but I do think syscalls should try to satisfy a > large number of user cases.
I don't think what is being proposed is trying to limit its use cases. The only limitation api wise was if we should return just nanoseconds or something with the potential for sub-ns values.
> > But again, the hard part with in-kernel TAI (possibly as the base of > > time)is that initialization of the TAI/UTC offset needs to be able to be > > phased in slowly, as we also have to preserve legacy interfaces and > > behavior. > > With brand new syscall, there are no legacy uses. > > > Why do we need a new interface for TAI? clock_gettime(CLOCK_TAI,...) > > should be achievable. I do think it would be interesting, but I also > > think its separate from the goal of this proposal. > > I mean to define an interface that always returns TAI values, no matter > what the clock device.
Maybe I'm still not understanding, but that seems more limited then what is being proposed, at least in my mind. clock_gettime_ns() would still take a clockid, so having a CLOCK_TAI would be a potential change in the future.
I don't see a reason to limit clock_gettime_ns() to only CLOCK_TAI. After all, while CLOCK_TAI doesn't have leapseconds, it still can be set by userland if its wrong, so it doesn't provide the same functionality as CLOCK_MONOTONIC. Additionally, the motivation for this new interface is for a more efficient CLOCK_THREAD_CPUTIME vdso implementation, so an exclusive CLOCK_TAI interface wouldn't serve that need.
I agree adding CLOCK_TAI is an interesting feature, but that could done properly with the existing clock_gettime() interface. So I think the CLOCK_TAI discussion is really disconnected from the new ABI being proposed.
thanks -john
| |