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

[Geoff Levand]

I'm thinking we should drop this discussion from LKML, and start a new 
thread on the high-res-timers-discourse list.  If anyone has an 
interest, please join us there:

<https://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse>

-Geoff

George Anzinger wrote:
> 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.


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