Re: [RFC 0/2] ABI for clock_gettime_ns

[john stultz]

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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/