gradual timeofday overhaul

From: Tim Schmielau
Date: Tue Oct 19 2004 - 22:21:41 EST


On Tue, 19 Oct 2004, john stultz wrote:

> As for the timeofday overhaul, I've had zero time to work on it
> recently. I hate that I dropped code and then went missing for weeks.
> I'll have to see if I can get a few cycles at home to sync up my current
> tree and send it out.

I still haven't looked at your code and it's discussion. From what I
remember, I liked your proposal very much. It's surely where we want to
end up someday. But from the above mail it strikes me that we just don't
have enough manpower to get there all at once, so we should have a plan
for the time code to gradually evolve into what we finally want. I think
we could do it in the following steps:

1. Sync up jiffies with the monotonic clock, very much like we
already handle lost ticks. This would immediately remove the
hassles with incompatible time sources.
Judging from the jiffies wrap experience, we there probably are
some drivers which need fixing (mostly because they wait until
jiffies==something), but these are bugs already right now
in the case of lost ticks.

2. Decouple jiffies from the actual interrupt counter. We could
then e.g. set HZ to 10000, also increasing the resolution of
timers, without increasing the interrupt frequency.
We'd then need to identify the places where this might lead to
overflows and promote them to use jiffies_64 instead of jiffies
(where this hasn't been done already).

3. Increase HZ all the way up to 1e9. jiffies_64 would then be the
same as your plain 64 bit nanoseconds value.
This would require an optimization to the timer code to be able
to increment jiffies in steps larger than 1.

Thoughts?

-
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/