lkml.org 
[lkml]   [2004]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [ANNOUNCE] high-res-timers patches for 2.6.6
Date
On Monday 14 June 2004 13:48, George Anzinger 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?
>
> Mostly I would like to make it "clean" enough to get the community to
> accept it. As I look at the current implemtation, the biggest intrusion
> into the "normal" kernel is in the timer list area. Thus, my thinking is
> to introduce a second or slave list which would only be used by HR timers.
> This list would be "checked" by putting a "normal" i.e. add_timer, timer in
> place to mark the jiffie that a HR timer was to expire in. The "check"
> code would then set up the HR interrupt to expire the timer.
>
> I am also considering removing a lot of the ifdefs one way or another.
> AND, I think I can make the whole thing configureable at boot time just as
> the pm/TSC/etc. timers are.
>

Sounds good to me. The higher level code can use this type of clean up.

> > 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.
>
> Uh, is this something like the current TSC/ pmtimer/ HPET/ PIT selection
> code in the x86? Or do you have something else in mind here. Given the
> goal of integration with and inclusion in the kernel.org kernel, I don't
> want to wander too far from what they are doing now.
>

Sort of but implemented with a dynamic binding as opposed to the current
compile time binding via ifdefs.

The current HRT code implements a kind of static / compile time polymorphism
that is hard for me to read and keep straight. It implements N time bases,
with M interrupt sources for K architectures. Implementing the binding logic
between all these at compile time leads to a lot of ifdefs and hard to grok
code.


> > * 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.
>
> I am not sure what wants to be done here. I have to keep in mind that x86
> is only one of many archs. I would like to keep it as simple as possible
> in this area. See the include/linux/hrtime.h file for the arch interface
> we are now using.
>

yes but the code in the include/linux/hrtime.h file exports zero abstractions
to the architecture independent kernel.

Its mostly a documentation header file, that includes the architecture
dependent exports, that then need to be used by the architecture independent
code. Its all wrapped up in macros and what not to make it work across a
handful of architectures but its still a significant CTAGS work out to follow
the logic.

I think that re-working the lower level HRT code to be more object based (like
pci and net devices for example) with a layered design would significantly
simplify the code and improve the extensibility across architectures and
platform hardware time based interrupt sources.

The only performance hit would be that some of the in-lined and compile time
macro code would no longer be inline-able.

--mgross

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.107 / U:0.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site