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

[George Anzinger <george@mvista.com>]

Geoff Levand wrote:
> George Anzinger wrote:
> 
>> 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.
>>
> 
> If that's the case, then Mark's proposal sounds like a good way to 
> abstract the arch dependent code.  Someone mentioned to me that distro 
> vendors would like the idea of runtime configuration because they could 
> use a single kernel binary to support many different hardware 
> configurations.  I suppose if needed some optimization can be done later.
> 
> Mark, do you have time to do a first cut at the interfaces?  It seems 
> you've been thinking about this, and I'd like to see your ideas.  It 
> would be great if you could put together a sample hrtime.h.  If you are 
> short on time, I could put something together, but I think you are the 
> guy to do this.
> 
>  From what I've been told, Renesas did an HRT port to the SH arch on a 
> recent kernel.  I'm trying to get the code so that there will be three 
> arch's (i386, ppc32 & sh) to work against when doing the arch 
> independent interface.

MV has ported HRT to PPC, MIPS, and, I think, a couple of ARM processors.
> 
> Another thing that seems to be a sore point is the HRT core.  I think 
> there's a good consensus that the current use of preprocessor 
> conditionals makes the code pretty hairy, but what alternatives are there?
> 
> If the HRT code is always compiled in, that would simplify things alot, 
> but then there would always be a small performance hit in the compares, 
> and a slightly bigger code size.  Is this acceptable?  Also, something 
> would need to be arranged to take care of the non-supported arch's.  Any 
> ideas here?

I think the best thing is to include an include/asm/hrtime.h in each arch.  The 
file could be empty.  (I, at one time, suggested a modification of the build 
environment such that such a file could be put in the asm-generic/ directory and 
would be found if no such file was found in the archs asm/ directory, but, alas, 
the powers that be DID NOT LIKE THAT.)  In any case, this would allow the 
including file (include/hrtime.h) to determine that the arch was not supported 
(i.e. it did not define the required functions) and define dummys that would 
satisfy the externals and also prevent the registration of the HR clocks.

> 
> Another way would be to pull out the HRT operations into separate 
> functions that could be conditionally included or replaced with no-op 
> versions based on a config option.  I don't know if this would be 
> do-able, or if the result would be very clean though...

As it stands "most" timer and clock functions are dispatched through the 
k_clocks array.  We don't use different functions here at this time except for 
the monotonic clock_settime(), but, if we wanted to duplicate most of the code, 
this might be a way to go.  (Note, that the current code has a test for 
existence of the function address and uses a default if no such exists.  This 
was to avoid the indirect function call which, I think, is rather expensive.)
> 
> George also mentioned an idea of a second 'timer slave list'.   Any 
> other ideas here?

I am tempted to send a message to Linus on this issue.  The problem is that 
separating the two lists adds overhead and is just not the clean way to do it. 
The up side is that those who don't want HRT will see less impact on the normal 
timer code.

Oh, and by the way, I welcome all the help you can give on these issues.  Thanks.
-- 
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