Re: [RFC PATCH 13/22 -v2] handle accurate time keeping over longdelays

[john stultz]

On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
> > Tony:  ia64 also needs something like this, but I found the fsyscall asm
> > bits a little difficult to grasp. So I'll need some assistance on how to
> > include the accumulated cycles into the final calculation.
> 
> I'm trying to figure out all the ramifications of the new
> "cycle_accumulated" field.  Does it really need to be
> propagated all the way to the low level assembler (which
> I don't want to mess with unless I really, really have to).
> Can't I do the necessary calculations in update_vsyscall()
> [Where I can do them in C :-)] and keep the same low
> level assembly code.  I think I must be missing some
> important bit of what is going on here.

(Added Bob Picco to the mail, as he was involved in the ia64 clocksource
work).

So the background on the patch is this:

Some clocksources wrap frequently (every few seconds, for example). This
can cause issues if we defer the update_wall_time() function where we
accumulate time for too long (this really only happens on -rt systems
right now). 

To avoid that issue, we've added the cycle_accumulated value, which acts
as a midpoint, where we can quickly accumulate cycles off of the
counter, without doing the more expensive update_wall_time() function.
This avoids issues with the clocksource wrapping, but requires that
cycle_accumulated be added in to the gettiemofday() calculation.

If you noticed in my email, the fix for ppc was a bit easier, as it has
only a 64bit counter that is quite unlikely to wrap twice between calls
to update_wall_time(). There we could decrement the cycles_last value by
cycles_accumulated and get the same effect of adding it in.

Unfortunately on ia64, I suspect it will be necessary to do similar to
the x86_64 code and add in the cycles accumulated value in
vgettime/fgettime function, since there is the possibility of quickly
wrapping clocksources on that architecture. 

So unless someone can point out a nicer trick, it likely means adding a
new cycles_accumulated value to the fsyscall structure and the asm to do
the addition. :(

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/