Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10)

[john stultz]

On Sun, 2005-11-13 at 02:24 +0100, Andi Kleen wrote:
> john stultz <johnstul@xxxxxxxxxx> writes:
> 
> > All,
> > 	I had hoped to submit this to -mm today, but since Ingo pointed
> > out an issue in the __delay code, I'm going to wait a week so the new fix
> > can be better tested.
> 
> At least on x86-64 there is currently so much other timer related
> development going on (per CPU TSC timers, no idle tick, 64bit HPET
> etc.)  that I don't want any x86-64 bits of that merged for the next
> time. The other stuff needs to settle first.

Oh yes, I should have been more clear. I'm not planning on submitting
the x86-64 bits yet, just the i386. The x86-64 parts are there as an
example that this is useful outside of just i386, and ensures the
framework can support more complex features, like vsyscall for example
(Also just to give some scope, I have code for ppc that I run at home
and code that builds for ppc64, s390, arm, sparc, alpha and ia64, but
all of those will need much more work).  

> I haven't read the patchset in full detail, but from a quick look
> it's also not obvious too me in which way it is easier and cleaner
> than the old setup. While the old code was quirky in parts the
> new one seems to fall more in the overmodularization/too many
> indirect callbacks trap.

I appreciate your time in looking at the code. I've added some
documentation in Documentation/timekeeping.txt, so let me know if
anything there needs further clarification.

However I don't feel it is overmodulation. The close linking between
timer interrupts and timekeeping is really problematic because any
change in one affects the other.  Further, examples like the list above
(for per-cpu TSC management and 64bit HPET timkeeping) show that the
code could use some modulation so these features can be developed beside
the already working implementations without serious conflicts.

> It is also totally unclear how it will interact with vsyscall.

vsyscall is probably adds the most complexity to the infrastructure, but
I feel I've addressed it in a pretty clean way. And it is working fine
for x86-64 and I have an additional patch that enables it for i386.

Take a look at the arch_update_vsyscall() function in the x86-64 code
and look at the vread() function in the x86-64 tsc clocksource. These
bits could use some cleaning up (I haven't removed the legacy time
variables that are exported), but the foundation is there. Please let me
know if you have any comments or suggestions for further simplifying
that code.

If you need more explanation, I can send the i386 code out on Monday,
which might show a more clear example.

Again, I really appreciate your feedback, and once I move my attention
off of getting the i386 code to Andrew, the x86-64 is the next arch I'll
be focusing on. So suggest away and I'll try to get the code to your
liking.

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/