Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 22 Jun 2005, john stultz wrote:

> Some other architectures try to handle these situations as well. One
> good example is PPC64 (which has greatly influenced my design). For
> correctness PPC64 goes as far as not using interpolation by avoiding
> almost all of the arch generic time code. It even has its own NTP
> adjustment code! 
> 
> I have come to believe the current arch generic tick based timekeeping
> is not sustainable. It seems to me in order to avoid bugs that customers
> are seeing, arches are going to have to avoid the current tick based
> arch generic code and implement their own non-interpolated based
> timekeeping code. So that is why I've created this proposal and
> implementation instead of just "fixing one issue".

I agree with you that the current time code is a problem for machines like 
ppc64, which basically use two different time sources.

We basically have two timer architectures: timer tick and continuous 
timer. The latter currently has to emulate the timer tick. Your patch 
completely reverses the rolls and forces everybody to produce a continuous 
timer, which I think is equally bad, as some simple computations become a 
lot more complex. Why should it not be possible to support both equally?

> So the question becomes: in order to achieve correctness, should every
> architecture implement a full timeofday subsystem of its own? I designed
> a system that would work, but instead of making it i386 and copying it
> for x86-64 and whatever else I end up working on, I propose we make it a
> common implementation.

That might result in the worst of both worlds. If I look at the ppc64 
implementation of gettimeofday, it's really nice and your (current) code 
would make this worse again. So why not leave it to the timer source, if 
it wants to manage a cycle counter or a xtime+offset? The common code can 
provide some helper functions to manage either of this. Converting 
everything to nanoseconds looks like a really bad compromise.

In the ppc64 example the main problem is that the generic tries to adjust 
for the wrong for the time source - the scheduler tick, which is derived 
from the cycle counter, so it has to redo all the work. Your code now 
introduces an abstract concept of nanosecond which adds extra overhead to 
either timer concept. Why not integrating what ppc64 does into the current 
timer code instead of replacing the current code with something else?

For tick based timer sources there is not much to do than incrementing 
xtime by precomputed constant. If I take ppc64 as an example for 
continuous time sources it does a lot less than your 
timeofday_periodic_hook(). Why is all this needed?
John, what I'd really like to see here is some math or code examples, 
which demonstrate how your new code is better compared to the old code. 
Your code makes a _huge_ transformation jump and I'd like you to explain 
some of the steps inbetween.

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