[ANNOUNCE] high-res-timers patches for 2.6.6

[ANNOUNCE] high-res-timers patches for 2.6.6

[Geoff Levand]

Available at 
http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive

For those interested, the set of three patches provide POSIX high-res 
timer support for linux-2.6.6.  The core and i386 patches are updates of 
George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
<http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
not available on SourceForge yet.

-Geoff

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

[William Lee Irwin III]

On Wed, Jun 09, 2004 at 06:49:29PM -0700, Geoff Levand wrote:
> Available at 
> http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
> For those interested, the set of three patches provide POSIX high-res 
> timer support for linux-2.6.6.  The core and i386 patches are updates of 
> George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
> <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
> not available on SourceForge yet.
> -Geoff

I thought George Anzinger's high resolution timer patches had already
been merged? At the very least there's already a kernel/posix-timers.c


-- wli

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

[eric.piel]

Quoting William Lee Irwin III <wli@holomorphy.com>:
> On Wed, Jun 09, 2004 at 06:49:29PM -0700, Geoff Levand wrote:
> > Available at 
> > http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
> > For those interested, the set of three patches provide POSIX high-res 
> > timer support for linux-2.6.6.  The core and i386 patches are updates of 
> > George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
> > <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
> > not available on SourceForge yet.
> > -Geoff
> 
> I thought George Anzinger's high resolution timer patches had already
> been merged? At the very least there's already a kernel/posix-timers.c

Not exactly, what has been merged is only the POSIX interface of the timers. The
patches to obtain a high resolution (in the order of 10 microseconds instead of
1ms) are still out from the vanilla kernel.

Eric

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

[William Lee Irwin III]

Quoting William Lee Irwin III <wli@holomorphy.com>:
>> I thought George Anzinger's high resolution timer patches had already
>> been merged? At the very least there's already a kernel/posix-timers.c

On Thu, Jun 10, 2004 at 10:40:55AM +0200, eric.piel@tremplin-utc.net wrote:
> Not exactly, what has been merged is only the POSIX interface of the time=
> rs. The patches to obtain a high resolution (in the order of 10
> microseconds instead of 1ms) are still out from the vanilla kernel.

That sounds useful. Any chance you could post them to lkml for review?
They're significantly less likely to actually be looked at and/or included
if ppl have to chase URL's. (That said, I personally don't have much of an
interest in all this, maybe others will speak up.)

Thanks.


-- wli

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

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Thu, 2004-06-10 at 03:49, Geoff Levand wrote:
> Available at 
> http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
> 
> For those interested, the set of three patches provide POSIX high-res 
> timer support for linux-2.6.6.  The core and i386 patches are updates of 
> George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
> <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
> not available on SourceForge yet.

My first impression is that it has WAAAAAAAAAAAY too many ifdefs. I
would strongly suggest to not make this a config option and just
mandatory, it's a core feature that has no point in being optional. If
you accept that, the code also becomes a *LOT* cleaner.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[George Anzinger]

Arjan van de Ven wrote:
> On Thu, 2004-06-10 at 03:49, Geoff Levand wrote:
> 
>>Available at 
>>http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
>>
>>For those interested, the set of three patches provide POSIX high-res 
>>timer support for linux-2.6.6.  The core and i386 patches are updates of 
>>George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
>><http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
>>not available on SourceForge yet.
> 
> 
> My first impression is that it has WAAAAAAAAAAAY too many ifdefs. I
> would strongly suggest to not make this a config option and just
> mandatory, it's a core feature that has no point in being optional. If
> you accept that, the code also becomes a *LOT* cleaner.
> 
Yes, but...  The main problem is that this would break all the archs that don't 
have the needed arch dependent code yet.  By making the high-res part depend on 
the arch config turning on a config, we don't break the archs and they can sign 
up as they get their act together.

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

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

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On Thu, Jun 10, 2004 at 05:02:23PM -0700, George Anzinger wrote:
> Arjan van de Ven wrote:
> >On Thu, 2004-06-10 at 03:49, Geoff Levand wrote:
> >
> >>Available at 
> >>http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
> >>
> >>For those interested, the set of three patches provide POSIX high-res 
> >>timer support for linux-2.6.6.  The core and i386 patches are updates of 
> >>George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
> >><http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
> >>not available on SourceForge yet.
> >
> >
> >My first impression is that it has WAAAAAAAAAAAY too many ifdefs. I
> >would strongly suggest to not make this a config option and just
> >mandatory, it's a core feature that has no point in being optional. If
> >you accept that, the code also becomes a *LOT* cleaner.
> >
> Yes, but...  The main problem is that this would break all the archs that 
> don't have the needed arch dependent code yet.  By making the high-res part 
> depend on the arch config turning on a config, we don't break the archs and 
> they can sign up as they get their act together.

if the price is this amount of uglyness then that's the wrong approach imo.
Would be nicer to make dummy helpers the arch people can just take during
the transition instead.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[George Anzinger]

Arjan van de Ven wrote:
> On Thu, Jun 10, 2004 at 05:02:23PM -0700, George Anzinger wrote:
> 
>>Arjan van de Ven wrote:
>>
>>>On Thu, 2004-06-10 at 03:49, Geoff Levand wrote:
>>>
>>>
>>>>Available at 
>>>>http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
>>>>
>>>>For those interested, the set of three patches provide POSIX high-res 
>>>>timer support for linux-2.6.6.  The core and i386 patches are updates of 
>>>>George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
>>>><http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
>>>>not available on SourceForge yet.
>>>
>>>
>>>My first impression is that it has WAAAAAAAAAAAY too many ifdefs. I
>>>would strongly suggest to not make this a config option and just
>>>mandatory, it's a core feature that has no point in being optional. If
>>>you accept that, the code also becomes a *LOT* cleaner.
>>>
>>
>>Yes, but...  The main problem is that this would break all the archs that 
>>don't have the needed arch dependent code yet.  By making the high-res part 
>>depend on the arch config turning on a config, we don't break the archs and 
>>they can sign up as they get their act together.
> 
> 
> if the price is this amount of uglyness then that's the wrong approach imo.
> Would be nicer to make dummy helpers the arch people can just take during
> the transition instead.

I have another solution, connected with the ability to turn it off at boot time. 
  Unsupporting archs would just not define a flag.

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

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

[George Anzinger]

Arjan van de Ven wrote:
> On Thu, Jun 10, 2004 at 05:02:23PM -0700, George Anzinger wrote:
> 
>>Arjan van de Ven wrote:
>>
>>>On Thu, 2004-06-10 at 03:49, Geoff Levand wrote:
>>>
>>>
>>>>Available at 
>>>>http://tree.celinuxforum.org/pubwiki/moin.cgi/CELinux_5fPatchArchive
>>>>
>>>>For those interested, the set of three patches provide POSIX high-res 
>>>>timer support for linux-2.6.6.  The core and i386 patches are updates of 
>>>>George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
>>>><http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
>>>>not available on SourceForge yet.
>>>
>>>
>>>My first impression is that it has WAAAAAAAAAAAY too many ifdefs. I
>>>would strongly suggest to not make this a config option and just
>>>mandatory, it's a core feature that has no point in being optional. If
>>>you accept that, the code also becomes a *LOT* cleaner.
>>>
Can I be so bold as to ask about the changed to the timer list code?  Assuming 
we scrapped all the ifdefs, that is.

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.

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

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

[Karim Yaghmour]

Geoff Levand wrote:
> For those interested, the set of three patches provide POSIX high-res 
> timer support for linux-2.6.6.  The core and i386 patches are updates of 
> George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
> <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
> not available on SourceForge yet.

I've got to ask:

Just reading from the Posix 1003.1b section 14 spec referenced by the HRT
main project page, I see the following:
------------------------------------------------------------------------------
Realtime applications must be able to operate on data within strict timing
constraints in order to schedule application or system events. Timing
requirements can be in response to the need for either high system throughput
or fast response time. Applications requiring high throughput may process
large amounts of data and use a continuous stream of data points equally
spaced in time. For example, electrocardiogram research uses a continuous
stream of data for qualitative and quantitative analysis.
------------------------------------------------------------------------------

If this is really the goal here, then why not just integrate Adeos into
the kernel and make some form of HRT as a loadable module that uses Adeos to
provide its services?

Currently Adeos runs on x86, ARM (MMU-full and MMU-less), PPC, so portability
is not an issue. Plus, the interface provided can either be directly used
by drivers to get hard-rt interrupts or it can be used by another layer to
provide more elaborate services (like RTAI or, potentially, HRT.) Using the
virtual interrupts that can be dynamically allocated at runtime, it's rather
easy to send signals between domains.

Sure, you may not have the exact Posix 1003.1b API, but I don't remember there
being any persistent goal of having the kernel conform to any standard.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

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

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Fri, Jun 11, 2004 at 03:33:38PM -0700, George Anzinger wrote:
> Can I be so bold as to ask about the changed to the timer list code?  
> Assuming we scrapped all the ifdefs, that is.

I wonder what kind of resolution is needed. I'd love for timers to just be
in "absolute time" using some fixed point arith, and then when the timer
queue gets run you look at the current time and run all the ones that
expired so far. That way you can make the HZ timer irq run this list, but if
it's cheap enough and you then want higher accuracy, also the RTC clock, and
potentially even some oddball thing like the idle loop or network interrupts
for network timers, or video vsync irqs or .. or ..


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Mark Gross]

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

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

[George Anzinger]

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

> * 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.

> * Finally a patch to integrate the first 3 with the POSIX timers code.
> 
> What do you think?
> 
> 
> --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/
> 

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

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

[George Anzinger]

Karim Yaghmour wrote:
> 
> Geoff Levand wrote:
> 
>> For those interested, the set of three patches provide POSIX high-res 
>> timer support for linux-2.6.6.  The core and i386 patches are updates 
>> of George Anzinger's hrtimers-2.6.5-1.0.patch available on SourceForge 
>> <http://sourceforge.net/projects/high-res-timers/>.  The ppc32 port is 
>> not available on SourceForge yet.
> 
> 
> I've got to ask:
> 
> Just reading from the Posix 1003.1b section 14 spec referenced by the HRT
> main project page, I see the following:
> ------------------------------------------------------------------------------ 
> 
> Realtime applications must be able to operate on data within strict timing
> constraints in order to schedule application or system events. Timing
> requirements can be in response to the need for either high system 
> throughput
> or fast response time. Applications requiring high throughput may process
> large amounts of data and use a continuous stream of data points equally
> spaced in time. For example, electrocardiogram research uses a continuous
> stream of data for qualitative and quantitative analysis.
> ------------------------------------------------------------------------------ 
> 
> 
> If this is really the goal here, then why not just integrate Adeos into
> the kernel and make some form of HRT as a loadable module that uses 
> Adeos to
> provide its services?
> 
> Currently Adeos runs on x86, ARM (MMU-full and MMU-less), PPC, so 
> portability
> is not an issue. Plus, the interface provided can either be directly used
> by drivers to get hard-rt interrupts or it can be used by another layer to
> provide more elaborate services (like RTAI or, potentially, HRT.) Using the
> virtual interrupts that can be dynamically allocated at runtime, it's 
> rather
> easy to send signals between domains.
> 
> Sure, you may not have the exact Posix 1003.1b API, but I don't remember 
> there
> being any persistent goal of having the kernel conform to any standard.

I don't see how this delivers any added value to the user.  I suppose code 
running at the kernel level might gain something, but at the user level we still 
have to deal with preemption latencies, which are the biggest problem (and, 
aside from messing up the accuracy of the timers, are NOT timer issues at all).

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

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

[Mark Gross]

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

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

[George Anzinger]

Mark Gross wrote:
> 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.
> 
What the 2.6 x86 timer code does is to "try" different clocks until they find 
one that "accepts" the job.  A boot time option can override this to force a 
given clock, but all are compile in.  (By the way, the first machine I wrote 
code for had a total of 8K bytes, so I really don't like to waste memory :))

I started to do this with the latest patch but stopped when I realized that I 
would have to redo the conversion code.  Still, this isn't too hard and I may 
finish this conversion.  This would eliminate the pm/ TSC configure option AND 
allow the user to completly eliminate the HR (buy choosing a non-HR option at 
boot time), which, by the way, he can do now.
> 
> 
>>>* 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.

I haven't looked at pci or net stuff lately, but my attmept to export the 
conversion_bits structure was dissed by the arch folks, so I went for just what 
was needed.  Some of them don't export a conversion to micro seconds conversion, 
for example.  I welcome more details...

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

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

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

[Mark Gross]

On Monday 14 June 2004 17:21, George Anzinger wrote:
> Mark Gross wrote:
> > 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.
>
> What the 2.6 x86 timer code does is to "try" different clocks until they
> find one that "accepts" the job.  A boot time option can override this to
> force a given clock, but all are compile in.  (By the way, the first
> machine I wrote code for had a total of 8K bytes, so I really don't like to
> waste memory :))
>
> I started to do this with the latest patch but stopped when I realized that
> I would have to redo the conversion code.  Still, this isn't too hard and I
> may finish this conversion.  This would eliminate the pm/ TSC configure
> option AND allow the user to completly eliminate the HR (buy choosing a
> non-HR option at boot time), which, by the way, he can do now.
>

Eliminating the PM/TSC configure option idea sounds good to me.  Are you 
talking about the code your private codebase or the patch from SF for 2.6.5?  

The code I'm looking at can't really do this, for the various time bases.  It 
chooses between including the conversion code from hrtime-Macpi.h ^ 
htrime-M586.h at compile time.   There can be no "try" different clocks with 
this linkage to the conversion code.

get_jiffies_time macro, is statically linked to get_arch_cycles who's 
implementation id dependent on which hrtime-M*.h is included in at build 
time.  Further the interpretation of "sub_left" is a function of the same 
build time configuration setting.

Grepping on USE_APIC_TIMERS shows more of the compile time ifdef code.  It 
cannot use APIC clocks unless its compiled into the kernel there can be no 
"try" different timers WRT the APIC timer.

> >>>* 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.
>
> I haven't looked at pci or net stuff lately, but my attmept to export the
> conversion_bits structure was dissed by the arch folks, so I went for just
> what was needed.  Some of them don't export a conversion to micro seconds
> conversion, for example.  I welcome more details...
>

Details...  Thats a hard thing to come by when in a high level design 
discussion.  

Its too bad the conversion_bits export got shot down.  Perhaps it was because 
you where exporting a data structure that made implicit assumptions rather 
than a more object based interface, with function pointers to conversion 
functions, and private data?

Regardless of doing an object based implementation of your design or not, if 
we could loose the #ifdefs and implicit ifdefs (i.e. IF_HIGH_RES) from the 
code (especially posix-timers.c) that would be really a good thing.

I do still like the object based design concept ;)


--mgross

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

[George Anzinger]

Mark Gross wrote:
> On Monday 14 June 2004 17:21, George Anzinger wrote:
> 
>>Mark Gross wrote:
>>
>>>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.
>>
>>What the 2.6 x86 timer code does is to "try" different clocks until they
>>find one that "accepts" the job.  A boot time option can override this to
>>force a given clock, but all are compile in.  (By the way, the first
>>machine I wrote code for had a total of 8K bytes, so I really don't like to
>>waste memory :))
>>
>>I started to do this with the latest patch but stopped when I realized that
>>I would have to redo the conversion code.  Still, this isn't too hard and I
>>may finish this conversion.  This would eliminate the pm/ TSC configure
>>option AND allow the user to completly eliminate the HR (buy choosing a
>>non-HR option at boot time), which, by the way, he can do now.
>>
> 
> 
> Eliminating the PM/TSC configure option idea sounds good to me.  Are you 
> talking about the code your private codebase or the patch from SF for 2.6.5?  

I started to to this in the 2.6.5 patch.  Some of it is still there, in that you 
can, at boot time, switch to one of the standard clocks and thus disable HRT (or 
I think you can as I have not tested this).
> 
> The code I'm looking at can't really do this, for the various time bases.  It 
> chooses between including the conversion code from hrtime-Macpi.h ^ 
> htrime-M586.h at compile time.   There can be no "try" different clocks with 
> this linkage to the conversion code.

Yes, I was looking at merging these two when I realized that the big thing they 
provide is different conversion routines.  Lately, however, I have been thinking 
that we can use the same routines and just changed the conversion_bits.
> 
> get_jiffies_time macro, is statically linked to get_arch_cycles who's 
> implementation id dependent on which hrtime-M*.h is included in at build 
> time.  Further the interpretation of "sub_left" is a function of the same 
> build time configuration setting.

I would like to handle this by using something like the timer get nanosecond 
stuff in the standard timers.

By the way, I have been talking to John Stultz about changing the code for 
gettimeofday to get nanoseconds and add that to xtime and THEN do the truncate 
to microseconds.  This would change the timers call interface as well.
> 
> Grepping on USE_APIC_TIMERS shows more of the compile time ifdef code.  It 
> cannot use APIC clocks unless its compiled into the kernel there can be no 
> "try" different timers WRT the APIC timer.

I had not considered not using the APIC timer if it was available.  Its 
availablity is a compile time thing.  It is used for both PM and TSC clocks and, 
I would assume, HPET when ever I get such a machine.
> 
> 
>>>>>* 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.
>>
>>I haven't looked at pci or net stuff lately, but my attmept to export the
>>conversion_bits structure was dissed by the arch folks, so I went for just
>>what was needed.  Some of them don't export a conversion to micro seconds
>>conversion, for example.  I welcome more details...
>>
> 
> 
> Details...  Thats a hard thing to come by when in a high level design 
> discussion.  
> 
> Its too bad the conversion_bits export got shot down.  Perhaps it was because 
> you where exporting a data structure that made implicit assumptions rather 
> than a more object based interface, with function pointers to conversion 
> functions, and private data?

The functions, of course, were also exported.  But this is exported from the 
arch side of things and not the base.  They need to provide the conversion 
functions, the bits just being somthing that is needed if they export inline 
code, where as, if they export the functions, they don't need the bits (i.e. 
they are private).  I rather like to export inline code as it is about twice as 
fast (I would guess).
> 
> Regardless of doing an object based implementation of your design or not, if 
> we could loose the #ifdefs and implicit ifdefs (i.e. IF_HIGH_RES) from the 
> code (especially posix-timers.c) that would be really a good thing.
> 
> I do still like the object based design concept ;)

I am afraid I am too old :(   I rather think I understand object based code 
while not finding it very "warm".   I have never written anything large that way 
and find myself objecting in the name of performance, but then, as I said, I may 
be too old.

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

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

[Mark Gross]

On Wednesday 16 June 2004 15:33, George Anzinger wrote:
> > Details...  Thats a hard thing to come by when in a high level design
> > discussion.  
> >
> > Its too bad the conversion_bits export got shot down.  Perhaps it was
> > because you where exporting a data structure that made implicit
> > assumptions rather than a more object based interface, with function
> > pointers to conversion functions, and private data?
>
> The functions, of course, were also exported.  But this is exported from
> the arch side of things and not the base.  They need to provide the
> conversion functions, the bits just being somthing that is needed if they
> export inline code, where as, if they export the functions, they don't need
> the bits (i.e. they are private).  I rather like to export inline code as
> it is about twice as fast (I would guess).

I think if in-lines are exported through more than one level of indirection 
through include files then the code is hard to grok.

>
> > Regardless of doing an object based implementation of your design or not,
> > if we could loose the #ifdefs and implicit ifdefs (i.e. IF_HIGH_RES) from
> > the code (especially posix-timers.c) that would be really a good thing.
> >
> > I do still like the object based design concept ;)
>
> I am afraid I am too old :(   I rather think I understand object based code
> while not finding it very "warm".   I have never written anything large
> that way and find myself objecting in the name of performance, but then, as
> I said, I may be too old.

Object based code good for some things, and not for others.  I think it could 
be a good match this code, but I bet it can be done well other ways as too.

I think without exporting abstractions (even just prototypes) that are common 
across architectures, timebases and interrupt source you will get into #ifdef 
hell with this code.


--mgross

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

[Karim Yaghmour]

George Anzinger wrote:
> I don't see how this delivers any added value to the user.  I suppose 
> code running at the kernel level might gain something, but at the user 
> level we still have to deal with preemption latencies, which are the 
> biggest problem (and, aside from messing up the accuracy of the timers, 
> are NOT timer issues at all).

Actually I think the point I'm trying to make can't be fairly conveyed
without providing a lot of background of what can be done with Adeos. I
would suggest that those interested do some digging. Among other things,
you may want to read about RTAI/fusion:
http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html
http://www.fdn.fr/~brouchou/rtai/modules.php?name=Content&pa=showpage&pid=1

Here's a quote from Philippe on how this compares to HRT:
> Last time I checked (i.e. two days ago on a 2.6.6), hi-res timers were
> not capable of providing 1Khz periodic timings for 10mn with no overrun
> through clock_nanosleep(), even with no additional load on the machine.
> fusion is able to do that directly through a plain nanosleep(); in fact
> it is able to sustain 10Khz periodic timings with a compilation, disk
> I/O and interrupt flooding in the background. Frankly, IMHO, determinism
> with really hi-res timing in user-space is a territory which will remain
> ruled by RTAI for quite a long time; vanilla Linux will always look
> miserable at some point in this respect unless, e.g. stuff like that
> (which is otherwise perfectly sound for a GPOS) disappears from its code
> base:
> 
> kernel/softirq.c:
> 
> /*
>  * We restart softirq processing MAX_SOFTIRQ_RESTART times,
>  * and we fall back to softirqd after that.
>  *
>  * This number has been established via experimentation.
>  * The two things to balance is latency against fairness -
>  * we want to handle softirqs as soon as possible, but they
>  * should not be able to lock up the box.
>  */
> #define MAX_SOFTIRQ_RESTART 10
> 
> asmlinkage void __do_softirq(void)
> 
> --
> 
> But, hey! I WANT to be able to lock up this box! :o)

Unfortunately, there's no sustained vendor push behind this kind of stuff
as their is for HRT, but my experience has been that this is for lack of
understanding of what Linux can/should be able to provide as a GPOS then
anything else (i.e. a lot of "embedded"/"carrier-grade" vendors seem to
somehow believe that eventually plain vanilla Linux could become hard-rt
simply by virtue of adding more and more features on top of it ...
preemption, HRT, interrupt threading, etc.etc.etc. While the fact of the
matter is that Linux is a GPOS and that it really should catter for the
average case and leave the hard-rt part to something built with that in
mind.) For having been involved with the use of Linux in real-time systems
for over 5 years now, I firmly believe any potential solution to determinism
in Linux goes through something like Adeos. The example of RTAI/fusion is
just one out of many of what can be achieved with such an approach while
making it simple for application developers to create applications built
on "standard" APIs.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

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

[George Anzinger]

Karim Yaghmour wrote:
> 
> George Anzinger wrote:
> 
>> I don't see how this delivers any added value to the user.  I suppose 
>> code running at the kernel level might gain something, but at the user 
>> level we still have to deal with preemption latencies, which are the 
>> biggest problem (and, aside from messing up the accuracy of the 
>> timers, are NOT timer issues at all).
> 
> 
> Actually I think the point I'm trying to make can't be fairly conveyed
> without providing a lot of background of what can be done with Adeos. I
> would suggest that those interested do some digging. Among other things,
> you may want to read about RTAI/fusion:
> http://www.fdn.fr/~brouchou/rtai/rtai-doc-prj/rtai-fusion.html
> http://www.fdn.fr/~brouchou/rtai/modules.php?name=Content&pa=showpage&pid=1
> 
> Here's a quote from Philippe on how this compares to HRT:
> 
>> Last time I checked (i.e. two days ago on a 2.6.6), hi-res timers were
>> not capable of providing 1Khz periodic timings for 10mn with no overrun
>> through clock_nanosleep(), even with no additional load on the machine.
>> fusion is able to do that directly through a plain nanosleep(); in fact
>> it is able to sustain 10Khz periodic timings with a compilation, disk
>> I/O and interrupt flooding in the background. Frankly, IMHO, determinism
>> with really hi-res timing in user-space is a territory which will remain
>> ruled by RTAI for quite a long time; vanilla Linux will always look
>> miserable at some point in this respect unless, e.g. stuff like that
>> (which is otherwise perfectly sound for a GPOS) disappears from its code
>> base:
>>
>> kernel/softirq.c:
>>
>> /*
>>  * We restart softirq processing MAX_SOFTIRQ_RESTART times,
>>  * and we fall back to softirqd after that.
>>  *
>>  * This number has been established via experimentation.
>>  * The two things to balance is latency against fairness -
>>  * we want to handle softirqs as soon as possible, but they
>>  * should not be able to lock up the box.
>>  */
>> #define MAX_SOFTIRQ_RESTART 10
>>
>> asmlinkage void __do_softirq(void)
>>
>> -- 
>>
>> But, hey! I WANT to be able to lock up this box! :o)
> 
> 
> Unfortunately, there's no sustained vendor push behind this kind of stuff
> as their is for HRT, but my experience has been that this is for lack of
> understanding of what Linux can/should be able to provide as a GPOS then
> anything else (i.e. a lot of "embedded"/"carrier-grade" vendors seem to

I think the real problem is an open source question.  The RTAI and RTLINUX folks 
are not exactly in the same camp (either with each other OR with LINUX) in this 
regard.  Should that change and one or more of these become truly open source 
without others claiming "foul", there are vendors who are ready and willing to 
work with the code.  Vendors of open source (and their customers) don't want to 
find themselves in law suits...

As such, this is really off topic...  as is a discussion of the merits of this 
sort of solution.  On this list we are interested in working in the confines of 
LINUX as found on linux.org possibly modified by truly open source patches and 
packages.


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

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

[Geoff Levand]

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

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

[Stephen Hemminger]

A couple of comments on posix-hrt-core-04.06.09.patch

1. Comment in hrtime.h is out of date, you are using seq_lock to do the read
   stuff now, an example is...

+ * Global locking issues: 
+ *
+ *      Time is locked with the xtime_lock using read/write locks.
+ *      Note: It is assumed that the do_timer() call is  protected by
+ *      write_lock(&xtime_lock).
+ *
+ *      Using code must not change, but only read, the protected
+ *      variables (xtime, jiffies, any temps tha need protection in the
+ *      arch_get_cycles() code).  Usage is as follows:
+ *
+ *      read_lock_irq(&xtime_lock);
+ *          do the reads
+ *      read_unlock_irq(&xtime)


2. Don't like new definition of running_timer; use explicit memory barriers
   not volatile please.

struct tvec_t_base_s {
 	spinlock_t lock;
 	unsigned long timer_jiffies;
-	struct timer_list *running_timer;
-	tvec_root_t tv1;
-	tvec_t tv2;
-	tvec_t tv3;
-	tvec_t tv4;
-	tvec_t tv5;
+ 	volatile struct timer_list * volatile running_timer;
+ 	struct list_head tv[NEW_TVEC_SIZE]line_aligned_in_smp;

3. The IF_HIGH_RES() macro looks cute, but get confusing, and makes the code
   less readable.

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

[George Anzinger]

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

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

[Randy.Dunlap]

On Mon, 21 Jun 2004 16:13:06 -0700 Stephen Hemminger wrote:

| A couple of comments on posix-hrt-core-04.06.09.patch

I haven't looked at the full patch lately, but...

| 3. The IF_HIGH_RES() macro looks cute, but get confusing, and makes the code
|    less readable.

this macro was always ugly and obfuscating to me.
Definitely need to lose it.

--
~Randy

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

[Mark Gross]

On Monday 21 June 2004 15:50, 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.
>

Runtime selection of time base's and interrupt sources for an HRT 
implementation may not be too useful in practice.  It sure would make testing 
and comparing different HRT configuration combonations easier.

I may have function pointers on the brain WRT this patch.  But, to get an 
implementation that exports a common abstraction across architectures, WRT 
time bases and interrupt sources, I don't see any other way than using the 
function pointers in a common structure.  It shouldn't matter much if it 
oppens up a feature that no one cares about (runtime selection on time base / 
interrupt source).

--mgross

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

[Karim Yaghmour]

George Anzinger wrote:
> I think the real problem is an open source question.  The RTAI and 
> RTLINUX folks are not exactly in the same camp (either with each other 
> OR with LINUX) in this regard.  Should that change and one or more of 
> these become truly open source without others claiming "foul", there are 
> vendors who are ready and willing to work with the code.  Vendors of 
> open source (and their customers) don't want to find themselves in law 
> suits...

There's no other way to call it: This is just plain ignorance.

If you care to actually look at the record, you will see that RTAI has
always been and will always been "open source". I'm not going to qualify
other peoples' claims against it, but let me just say that you've
succumbed to FUD, ant THAT is totally pathetic.

I personally don't see why Linux's future should be dictated by a bunch
of worried PHBs who haven't even cared to research the case. Following
you logic, maybe we should just all stop using Linux altogether just in
case SCO sues.

> As such, this is really off topic...  as is a discussion of the merits 
> of this sort of solution.  On this list we are interested in working in 
> the confines of LINUX as found on linux.org possibly modified by truly 
> open source patches and packages.

Again, you don't know what you're talking about. If you have any actual,
factual and timely claim against RTAI, then please voice it now.
Otherwise, this is plain misleading. Not to mention that offloading
something so foreign as hard-rt into a module is actually not that
unlike Linux as many vendors, including your employer, claim it to be.

Note that my entire point was about how Adeos could be used as an engine
for providing much more than HRT could ever provide. Adeos has always
been independent from RTAI and is based entirely on scientific publications
that predate the patent. As has been proven on this list, any claim that
it is somehow covered by the patent is patently absurd. So whether you
buy the FUD against RTAI or not is really inconsequential. The real issue
is what Adeos can provide that HRT and all the other wannabee solutions
just can't provide.

If FUD is what is driving you to get HRT into Linux, it would just go to
show that you have a very poor understanding of what Linux is about.

I take it, though, that since you haven't actually countered my argument,
you actually agree with me that RTAI/fusion on Adeos is a far superior
solution to HRT on technical terms. Given that you've agreed with that,
I'd encourage you now to actually read up on the topic of RTAI and
open source so that you too can join in working on RTAI/fusion, and stop
the time-waste that HRT is.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546

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

[Geoff Levand]

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.

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?

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

George also mentioned an idea of a second 'timer slave list'.   Any 
other ideas here?


-Geoff

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

[Stephen Hemminger]

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

The way to handle this is to abstract the needed interface
into a set of inline's in one place (hrtime.h) then something like

#ifdef CONFIG_HIRES_TIMERS

static inline void update_hires(struct foo *foo) {
	foo->sub_tick = ...
}
#else

static inline void update_hires(struct foo *foo) {
}

#endif

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

There are two different questions. Should size of structures change based on
config options, that is what tends to make binaries break. The other is whether
the sub-tick stuff is implemented or not.


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

It is best if the conditional code is in only a few of places,
like the inline's in an one include file; and the main code in timers
plus any arch dependant stuff.


-- 
Stephen Hemminger 		mailto:shemminger@osdl.org
Open Source Development Lab	http://developer.osdl.org/shemminger

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

[George Anzinger]

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

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.

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

[Mark Gross]

On Tuesday 22 June 2004 10:37, 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

I'm sorry, but I'm very much behind schedule on the ipw2200 driver and shouldn't even 
be taking the time to read LKML right now.  And likely won't for a while.

However; I was thinking of a simple structure with a few function pionters and perhaps some 
data, a pointer to arch specific private data.

struct {
	void *hrt_arch_priv; /* <-- perhaps not useful TBD */
	function pointer to time convertion function to sub_jiffies hrt_to_sub_jiffies(...);
	function pointer to get number of sub_jiffies since last jiffie hrt_sub_jiffies();
	function pointer to setting next initerrupt hrt_program_int( sub_jiffes_from_now);
	function pointer to getting current drift between system clock and hrt time base hrt_drift(...);
	function pointer to drift correction WRT system clock hrt_sync(...);
	};
It would be easiest to grock if sub_jiffies units where fixed, say nano or micro seconds.

--mgross

> 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.
>
> 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?
>
> 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...
>
> George also mentioned an idea of a second 'timer slave list'.   Any
> other ideas here?
>
>
> -Geoff
>
>
>
>
> -
> 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/

[ANNOUNCE] high-res-timers patch

[Geoff Levand]

For those interested, I migrated George Anzinger's high-res-timers patch 
to linux-2.6.8.1.

Available at:
<http://tree.celinuxforum.org/pubwiki/moin.cgi/PatchArchive>

The set of patches provide POSIX high resolution timer support.  See the 
SourceForge project pages for more info: 
<http://sourceforge.net/projects/high-res-timers/>.

-Geoff

[ANNOUNCE] high-res-timers patch

[Geoff Levand]

For those interested, I prepared a set of high resolution timers 
patches against linux-2.6.9:

<http://sourceforge.net/project/showfiles.php?group_id=20460&package_id=63076&release_id=280281>

New for this release is support for the SH architecture.  This SH
support is to be considered experimental though.  Please send
comments to the project mailing list:
 
<high-res-timers-discourse@lists.sourceforge.net>

This set of patches provide POSIX high resolution timer support.
For more info see the SourceForge project pages:
 
<http://sourceforge.net/projects/high-res-timers/>.

-Geoff