Messages in this thread | | | Date | Wed, 29 Oct 2014 10:40:00 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH v7] timekeeping: Added a function to return tv_sec portion of ktime_get_ts64() |
| |
On Wed, 29 Oct 2014, Arnd Bergmann wrote:
> On Wednesday 29 October 2014 10:21:18 Thomas Gleixner wrote: > > On Wed, 29 Oct 2014, Heena Sirwani wrote: > > > +time64_t ktime_get_seconds(void) > > > +{ > > > + time64_t seconds; > > > + struct timekeeper *tk = &tk_core.timekeeper; > > > + unsigned int seq; > > > + > > > + WARN_ON(timekeeping_suspended); > > > > You want to have the same 64bit logic as you did for > > ktime_get_real_seconds. So on 64bit it boils down to return > > tk->ktime_sec. > > > > > + > > > + do { > > > + seq = read_seqcount_begin(&tk_core.seq); > > > + seconds = tk->ktime_sec; > > > + > > > + } while (read_seqcount_retry(&tk_core.seq, seq)); > > > > I wonder if we should just make tk->ktime_sec 'unsigned long' and > avoid the lock for 32-bit as well. Are there any theoretical > cases where the monotonic time could overflow a 32-bit integer?
136 years uptime :) I think we discussed that 32bit thing before, but I forgot again.
> As a minor optimization 's64 nsec_offset' could also be 'long', > since that only stores a number that is known to be less than > 1000000000.
Indeed.
Thanks,
tglx
| |