Date:	Wed, 14 Dec 2011 08:48:30 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org, Kumar Sundararajan <kumar@...com>,
	Arun Sharma <asharma@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC 0/2] ABI for clock_gettime_ns

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

> > That being said, it might be nice to do something about leap seconds.
> > I always thought that the nanosecond count should include every
> > possible leap second so that every time that actually happens
> > corresponds to a unique count, but maybe that's just me.
> 
> The advantage of working with TAI is that you can use simple addition
> and substraction (converting the result to UTC or whatever), and the
> answer is always correct.

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. 

> > >> - Sub nanosecond field
> > 
> > Me.  A nanosecond is approximately a light-second.  Other than things
> > local to a single computer, not much of interest happens on a
> > sub-nanosecond time scale.  Also, a single 64-bit count is nice, and
> > 2^64 picoseconds isn't very long.
> 
> Believe it or not, people (from the Test and Measurement field) have
> already been asking me about having subnanosecond time values from the
> kernel.
> 
> What about this sort of time value?
> 
> struct sys_timeval {
> 	__s64 nanoseconds;
> 	__u32 fractional_ns;
> };
> 
> The second field can just be zero, for now.

I'm mixed on this. 

We could do this, as the kernel keeps track of sub-ns granularity.
However, its not stored in a decimal format. So I worry the extra math
needed to convert it to something usable might add extra overhead,
removing the gain of the proposed clock_gettime_ns() interface.


> > >> - TAI time base (or according to parameter?)
> > >
> > > Having a CLOCK_TAI would be interesting across the board. We already
> > > keep a TAI offset in the ntp code. However, I'm not sure if ntp actually
> > > sets it these days.
> > 
> > A friend of mine would probably appreciate various barycentric time
> > scales as well.  This would also be a different (and unrelated) patch.
> 
> What about this: a new, non-POSIX, rational time interface providing
> TAI time values, and a user space library for time scale conversion?

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.

thanks
-john


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

Powered by blists - more mailing lists