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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
