Re: clocksource

[john stultz <johnstul@us.ibm.com>]

On Mon, 2006-06-05 at 01:50 +0200, Roman Zippel wrote:
> Hi,
> 
> On Sun, 4 Jun 2006, Andrew Morton wrote:
> 
> > time-use-clocksource-infrastructure-for-update_wall_time.patch
> 
> I still disagree with the update_wall_time() changes, they should be kept 
> the new separate from this. 

Is this directly related to the next item (if so, how?), or just
preference? I'd really like to avoid having multiple code paths for the
timekeeping core, so I'd like to see this unified. I'm willing to
optimize out bits w/ constants and whatnot, but I worry it will be a
nightmare to maintain if we have multiple generic update_wall_time
implementations.

> The error algorithm is a somewhat old version 
> and can cause oscillation and thus a confused clock.

Would you mind elaborating on this? Which aspect of the error algorithm
is off? How does the clock become confused? Could you point to the line
numbers, etc?  I assume your last patchset contains the current version?

> > time-let-user-request-precision-from-current_tick_length.patch
> 
> This is broken, as it simply throws away resolution depending on the 
> clock.

So if the clock shift value is less then 12 (SHIFT_SCALE - 10), this is
true, and currently that's only the jiffies case.

Just to be clear, are you then suggesting that the accumulation in
update_wall_time should be done in a fixed shifted nanosecond unit
regardless of the clock shift value? Is SHIFT_SCALE-10, good enough in
your mind for this?

That seems not too difficult to do, and can be done w/ an incremental
patch. I'll try to crank that out today.

> These are two key problems, the rest can be fixed incrementally.

If these are really blockers, I want to get them resolved in the next
day or so (I'd really like to avoid having Andrew carry them for yet
another cycle). So I'd appreciate your help in correcting these issues.

thanks
-john