lkml.org 
[lkml]   [2014]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 14/55] timekeeping: Provide internal ktime_t based data
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 have to just put up with it, but I'd like to start thinking
> about how to reduce the duplicated data in the future. Arnd had an
> interesting idea for something like storing fixed point seconds, which
> could be cheaply converted to either ktime_t or timespec values.
> However, I suspect that would be even more complex for folks to
> understand, which I'd rather not do.
>
> Overall, it might be best if we just kill the timespec
> wall_to_monotonic/total_sleep_time/tai_offset values and keep the
> timekeeper values almost all in timespecs. Then we can leave the

So we kill the time specs and store everything in timespecs :)

> conversion process to basically cache the timespec values to the
> vsyscall_update logic?

> Or if we do want to maintain performance for non-vdso implementations,
> maybe we can split the timespec functions out of the timekeeping core
> and do a similar single shot update each tick to set the update the
> tiemspec cached values. But that can be layered over the timekeeping
> core and we can avoid the crazy updating 2 values any time we change
> one logic we currently have.

Makes sense. Lemme have a stab on it.

Thanks,

tglx


\
 
 \ /
  Last update: 2014-07-16 09:41    [W:0.409 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site