Date:	Sat, 25 Oct 2014 17:39:38 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Heena Sirwani <heenasirwani@...il.com>,
	linux-kernel@...r.kernel.org, john.stultz@...aro.org
Subject: Re: [PATCH v5] timekeeping: Added a function to return tv_sec portion of ktime_get_ts64()

On Saturday 25 October 2014 17:22:23 Thomas Gleixner wrote:
> On Sat, 25 Oct 2014, Thomas Gleixner wrote:
> > On Sat, 25 Oct 2014, Heena Sirwani wrote:
> > > +time64_t ktime_get_seconds(void)
> > > +{
> > > +   time64_t ts;
> > > +   struct timekeeper *tk = &tk_core.timekeeper;
> > > +   struct timespec64 tomono;
> > > +   s32 nsec;
> > > +   unsigned int seq;
> > > +
> > > +   WARN_ON(timekeeping_suspended);
> > > +
> > > +   do {
> > > +           seq = read_seqcount_begin(&tk_core.seq);
> > > +           ts = tk->xtime_sec;
> > > +           nsec = (long)(tk->tkr.xtime_nsec >> tk->tkr.shift);
> > > +           tomono = tk->wall_to_monotonic;
> > > +
> > > +   } while (read_seqcount_retry(&tk_core.seq, seq));
> > > +
> > > +   ts += tomono.tv_sec;
> > > +   if (nsec + tomono.tv_nsec >= NSEC_PER_SEC)
> > > +           ts += 1;
> > > +   return ts;
> > 
> > I'd rather have an extra field in the timekeeper
> > 
> >     u64 xtime_sec;
> > +   u64 ktime_sec;
> > 
> > and update this in tk_update_ktime_data() so the readout function
> > boils down to
> > 
> > time64_t ktime_get_seconds(void)
> > {
> > #if BITS_PER_LONG < 64
> >       u64 sec;
> >       int seq;
> > 
> >       do {
> >               seq = read_seqcount_begin(&tk_core.seq);
> >               sec = tk->ktime_sec;
> >       } while (read_seqcount_retry(&tk_core.seq, seq));
> > 
> >       return sec;
> > #else
> >       return tk->ktime_sec;
> > #endif
> > }
> > 
> > So 64bit can do w/o the seqcount and 32bit avoids all extra math, right?
> 
> Hmm. Thinking more about it. That's actually overkill. For ktime_sec a
> 32bit value is plenty enough unless we care about systems with more
> than 136 years uptime. So if we calculate the seconds value of ktime,
> i.e. CLOCK_MONOTONIC, in the update function, we can read it on both
> 32 and 64bit w/o the seqcount loop.

Ah, very good point. That opens the question which type that function
should return. I really want to remove all uses of time_t from the
kernel, mostly so we know when we're done with this. However as you
say we know that we only need a 32-bit value here. Some possible
ideas:

- use time64_t here anyway and accept the slight inefficiency in return
  for clarity
- introduce a monotonic_time_t (we probably also want a struct
  monotonic_timespec if we do that) which is basically the old time_t
  but is known to be y2038 safe because we only ever use it to store
  monotonic times.
- return u32 and use the same type in the callers instead of
  time_t/time64_t/monotonic_time_t.

> Where we really need the above readout mechanism is get_seconds() as
> that will break in 2038 on 32bit. So there you need to change the
> return value from unsigned long to time64_t and change the
> implementation as above just xtime_sec instead of ktime_sec.

Heena already posted a first draft of that patch to the opw internal
mailing list, I found a small issue that needs to be resolved and
then she can post the new version to you for review.

	Arnd
--
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