Re: [ANNOUNCE] high-res-timers patches for 2.6.6
From: Geoff Levand
Date: Mon Jun 21 2004 - 17:53:35 EST
Mark Gross wrote:
On Friday 11 June 2004 15:33, George Anzinger wrote:
I have been thinking of a major rewrite which would leave this code alone,
but would introduce an additional list and, of course, overhead for
high-res timers. This will take some time and be sub optimal, so I wonder
if it is needed.
What would your goal for the major rewrite be?
Redesign the implementation?
Clean up / re-factor the current design?
Add features?
I've been wondering lately if a significant restructuring of the
implementation could be done. Something bottom's up that enabled changing /
using different time bases without rebooting and coexisted nicely with HPET.
Something along the lines of;
* abstracting the time base's, calibration and computation of the next
interrupt time into a polymorphic interface along with the implementation of
a few of your time bases (ACPI, TSC) as a stand allown patch.
* implement yet another polymorphic interface for the interrupt source used by
the patch, along with a few interrupt sources (PIT, APIC, HPET <-- new )
* Implement a simple RTC-like charactor driver using the above for testing and
integration.
* Finally a patch to integrate the first 3 with the POSIX timers code.
What do you think?
--mgross
Mark,
Generally I agree with your ideas on what needs fixing up, but I'm
concerned that the run-time binding of this kind of design would have
too much overhead for time-critical code paths. Do you think it is
useful to have run-time selection of the time base and interrupt source?
In my work we have a known fixed hardware configuration that has
limited timers, so I don't really see a need for runtime configuration
there.
-Geoff
-
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/