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
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
Quoting William Lee Irwin III <[email protected]>:
> 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
Quoting William Lee Irwin III <[email protected]>:
>> 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, [email protected] 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
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.
Please keep in mind that some people just want the VST portion, and
don't want the high-res-timers portion (i.e. my ARM platform doesn't
have or need the hardware side of things). This may not be relevant to
your discussion of the ifdef's, but on the off chance that it was
somehow, I thought I would throw that out.
--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> On Behalf Of Arjan van de Ven
> Sent: Thursday, June 10, 2004 3:04 AM
> To: Geoff Levand
> Cc: [email protected];
> [email protected]; George Anzinger
> Subject: Re: [ANNOUNCE] high-res-timers patches for 2.6.6
>
>
> 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.
>
>
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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.
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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 || [email protected] || 1-866-677-4546
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 ..
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 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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
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 || [email protected] || 1-866-677-4546
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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
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.
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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
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
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 || [email protected] || 1-866-677-4546
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
>
> 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:[email protected]
Open Source Development Lab http://developer.osdl.org/shemminger
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 [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
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.
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/