Re: [ANNOUNCE] high-res-timers patches for 2.6.6

[Mark Gross]

On Monday 21 June 2004 15:50, Geoff Levand wrote:
> 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.
>

Runtime selection of time base's and interrupt sources for an HRT 
implementation may not be too useful in practice.  It sure would make testing 
and comparing different HRT configuration combonations easier.

I may have function pointers on the brain WRT this patch.  But, to get an 
implementation that exports a common abstraction across architectures, WRT 
time bases and interrupt sources, I don't see any other way than using the 
function pointers in a common structure.  It shouldn't matter much if it 
oppens up a feature that no one cares about (runtime selection on time base / 
interrupt source).

--mgross

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