Re: [patch 14/55] timekeeping: Provide internal ktime_t based data

2014-07-16 Thread Peter Zijlstra
On Wed, Jul 16, 2014 at 09:12:52AM +0200, Thomas Gleixner wrote: > Looking into it I think for now it's the least risky approach to keep > the core logic based on the timespec stuff unmodified and update the > ktime_t members in timekeeping_update(). Converting the whole thing to > a pure nsec base

Re: [patch 14/55] timekeeping: Provide internal ktime_t based data

2014-07-16 Thread Thomas Gleixner
On Wed, 16 Jul 2014, Thomas Gleixner wrote: > On Tue, 15 Jul 2014, John Stultz wrote: > > Hrmm.. So I do understand why this is useful performance wise. > > However, I'm really starting to feel that keeping all this duplicate > > data is a real maintenance burden, as remembering to keep the values

Re: [patch 14/55] timekeeping: Provide internal ktime_t based data

2014-07-16 Thread Thomas Gleixner
On Tue, 15 Jul 2014, John Stultz wrote: > Hrmm.. So I do understand why this is useful performance wise. > However, I'm really starting to feel that keeping all this duplicate > data is a real maintenance burden, as remembering to keep the values > in sync always is prone to error. > > So I may ha

Re: [patch 14/55] timekeeping: Provide internal ktime_t based data

2014-07-15 Thread John Stultz
On Fri, Jul 11, 2014 at 6:44 AM, Thomas Gleixner wrote: > The ktime_t based interfaces are used a lot in performance critical > code pathes. Add ktime_t based data so the interfaces don't have to > convert from the xtime/timespec based data. > > Signed-off-by: Thomas Gleixner > --- > include/lin