Message-ID: <alpine.DEB.2.11.1410281219360.5308@nanos>
Date:	Tue, 28 Oct 2014 12:26:15 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.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 Sun, 26 Oct 2014, Arnd Bergmann wrote:
> On Saturday 25 October 2014 19:32:09 Thomas Gleixner wrote:
> > On Sat, 25 Oct 2014, Arnd Bergmann wrote:
> > > On Saturday 25 October 2014 17:22:23 Thomas Gleixner wrote:
> > > > 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
> > 
> > Probably the simplest option.
> > 
> > > - 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.
> > 
> > Not sure whether its worth the trouble.
> 
> We have around 20 drivers using ktime_get_ts() or getrawmonotonic().
> If we had a 'struct monotonic_timespec', we could trivially convert
> them, otherwise we have to look at each one individually to figure
> out what they should use, in particular if they would have noticeably
> worse performance by moving to ktime_get_ts64 or getrawmonotonic64.
> 
> The way to do that would be to add 
> 
> #define monotonic_timespec timespec
> 
> now, and rename timespec to monotonic_timespec after we are done
> converting all other in-kernel users of timespec. There are probably

You can't do that because timespec will have to stay for the "compat"
syscalls.

> a few drivers that today use do_gettimeofday or getnstimeofday that
> could be converted to use ktime_get_ts using a 32-bit
> monotonic_timespec.
> 
> The alternative to that would be to make them all use ktime_t, which
> might be more efficient but also more work to do.

If you touch a file anyway then you better chose the best
solution. The only reason why you want to use the less work option is
if you can do a conversion scripted w/o actually analyzing each
changed file deeply.

> > > - return u32 and use the same type in the callers instead of
> > >   time_t/time64_t/monotonic_time_t.
> > 
> > Works as well. I have no immediate preference.
> 
> I think I like the u32 approach better than ktime_t, but it's a
> very mild preference. I'll wait for your reply on the monotonic_time_t/
> monotonic_timespec comments above. Maybe John has an opinion as well.

You really should look at the call sites and judge based on the
requirements of those.

Thanks,

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