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

[George Anzinger <george@mvista.com>]

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.

Well, I don't see much added overhead, (save memory).  We already dispatch 
interrupts via indirect function calls in irq.c.  And the core clock functions 
(used by gettimeofday, for example) are also indirected today (this to allow 
pm-timer, TSC, or PIT at boot time).  All we would do is put both of our 
possibilities in the list.  The only place we add overhead is in an indirect to 
the "proper" hardware timer for the sub-jiffie interrupt.


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml