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

[Geoff Levand <geoffrey.levand@am.sony.com>]

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