Re: [Xenomai-core] Timer optimisations, continued
On Thu, 2006-07-27 at 15:54 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > On Thu, 2006-07-27 at 14:42 +0200, Gilles Chanteperdrix wrote: > >> Philippe Gerum wrote: > >> > > o A further improvement should be achievable for scenarios 4 and 5 by > >> > >introducing absolute xntimers (more precisely: a flag to > >> > >differentiate between the mode on xntimer_start). I have an > >> outdated > >> > >patch for this in my repos, needs re-basing. > >> > > > >> > > >> > Grmblm... Well, I would have preferred that we don't add that kind of > >> > complexity to the nucleus interface, but I must admit that some > >> > important use cases are definitely better served by absolute timespecs, > >> > so I would surrender to this requirement, provided the implementation is > >> > confined to xnpod_suspend_thread() + xntimer_start(). > >> > >> It would be nice if absolute timeouts were also available when using > >> xnsynch_sleep_on. There are a few use cases in the POSIX skin. > > > > Makes sense, since xnpod_suspend_thread() and xnsynch_sleep_on() are > > tightly integrated interfaces. > > > > Anyone any idea how to extend both function interfaces best to > differentiate absolute/relative timeouts? I guess we need an additional > argument to the functions, don't we? Yes, I'm afraid we do. The other approach that would basically make the timeout a non-scalar value in order to store the rel/abs qualifier would be just overkill. > > I had the weird idea of using the sign bit of the timeout value for > this. But the potential side effects of halving the absolute time domain > this way scares me. > Same here, this looks like a very fragile solution to a general issue. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Timer optimisations, continued
Philippe Gerum wrote: > On Thu, 2006-07-27 at 14:42 +0200, Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >> > > o A further improvement should be achievable for scenarios 4 and 5 by >> > >introducing absolute xntimers (more precisely: a flag to >> > >differentiate between the mode on xntimer_start). I have an outdated >> > >patch for this in my repos, needs re-basing. >> > > >> > >> > Grmblm... Well, I would have preferred that we don't add that kind of >> > complexity to the nucleus interface, but I must admit that some >> > important use cases are definitely better served by absolute timespecs, >> > so I would surrender to this requirement, provided the implementation is >> > confined to xnpod_suspend_thread() + xntimer_start(). >> >> It would be nice if absolute timeouts were also available when using >> xnsynch_sleep_on. There are a few use cases in the POSIX skin. > > Makes sense, since xnpod_suspend_thread() and xnsynch_sleep_on() are > tightly integrated interfaces. > Anyone any idea how to extend both function interfaces best to differentiate absolute/relative timeouts? I guess we need an additional argument to the functions, don't we? I had the weird idea of using the sign bit of the timeout value for this. But the potential side effects of halving the absolute time domain this way scares me. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Timer optimisations, continued
On Thu, 2006-07-27 at 14:42 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > > o A further improvement should be achievable for scenarios 4 and 5 by > > >introducing absolute xntimers (more precisely: a flag to > > >differentiate between the mode on xntimer_start). I have an outdated > > >patch for this in my repos, needs re-basing. > > > > > > > Grmblm... Well, I would have preferred that we don't add that kind of > > complexity to the nucleus interface, but I must admit that some > > important use cases are definitely better served by absolute timespecs, > > so I would surrender to this requirement, provided the implementation is > > confined to xnpod_suspend_thread() + xntimer_start(). > > It would be nice if absolute timeouts were also available when using > xnsynch_sleep_on. There are a few use cases in the POSIX skin. Makes sense, since xnpod_suspend_thread() and xnsynch_sleep_on() are tightly integrated interfaces. > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Timer optimisations, continued
Philippe Gerum wrote: > > o A further improvement should be achievable for scenarios 4 and 5 by > >introducing absolute xntimers (more precisely: a flag to > >differentiate between the mode on xntimer_start). I have an outdated > >patch for this in my repos, needs re-basing. > > > > Grmblm... Well, I would have preferred that we don't add that kind of > complexity to the nucleus interface, but I must admit that some > important use cases are definitely better served by absolute timespecs, > so I would surrender to this requirement, provided the implementation is > confined to xnpod_suspend_thread() + xntimer_start(). It would be nice if absolute timeouts were also available when using xnsynch_sleep_on. There are a few use cases in the POSIX skin. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Timer optimisations, continued
On Tue, 2006-07-25 at 20:26 +0200, Jan Kiszka wrote: > > To summarise these lengthy results: > > o ns-based xntimers are nice on first sight, but not on second. Most >use-cases (except 5) require less conversions when we keep the >abstraction as it is. > The current approach was a deliberate choice to favour accuracy of timers, at the - reasonably small - expense of not optimizing the "timeout" use case. The net result is that the core timing code is TSC-based, so that no time unit conversion occurs after a timer has been started, except in the case where the hw timer has a different time unit than the TSC used (this said, this last conversion before programmin gthe hw timer would be needed regardless of the time unit maintained by the timing core). > o Performance should be improvable by combining fast_tsc_to_ns for full >64-bit conversions with nodiv_imuldiv for short relative ns-to-tsc. >It should be ok to loose some accuracy wrt to long periods given that >TSC are AFAIK not very accurate themselves. Nevertheless, to keep >precision on 64-bit ns-to-tsc reverse conversions, those should >remain implemented as they are: >"if (ns <= ULONG_MAX) nodiv_imuldiv else xnarch_ns_to_tsc" > I basically agree with that, including the 64/32 optimization on delay ranges. IOW, we could optimize time conversions in the timing core _locally_ (i.e. nucleus/timer.c exclusively) even at the expense of a small loss of accuracy in the dedicated converters. In any case, we are implicitely talking of the oneshot mode here, and as such, it would be acceptable to trigger an early shot once in a while - i.e. due to the loss of accuracy - that would cause the existing code to restart the timer until it eventually elapses past the expected time, given that this would only occur with large delays. But: we must leave the existing converters as they are in the xnarch layer, keeping the most accurate operations provided there, since a lot of code depends on their accuracy. > o A further improvement should be achievable for scenarios 4 and 5 by >introducing absolute xntimers (more precisely: a flag to >differentiate between the mode on xntimer_start). I have an outdated >patch for this in my repos, needs re-basing. > Grmblm... Well, I would have preferred that we don't add that kind of complexity to the nucleus interface, but I must admit that some important use cases are definitely better served by absolute timespecs, so I would surrender to this requirement, provided the implementation is confined to xnpod_suspend_thread() + xntimer_start(). > To verify that we actually improve something with each of the changes > above, some kind of fine-grained test suite will be required. The > timerbench could be extended to support all 5 scenarios. But does > someone have any quick idea how to evaluate the overall performances > best? The new per-task statistics code is not accurate enough as it > accounts IRQs mostly to the preempted task, not the preempting one. Mm, > execution time of some long-running number-crunching Linux task in the > background? Better use a kernel-based low priority RT task running in the background, limiting the sampling period to a duration that Linux could bear with (maybe running multiple subsequent periods with warmup phases, just to let the penguin breath). The effect of TLB misses would be much lower, and no need to block the Linux IRQs using Xenomai's I-shield. > Looking forward to feedback! > > Jan > > > PS: Finally, after stabilising the xntimers again, we will see a nice > rtdm_timer API as well. But those patches need even more re-basing then... > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] timer optimisations
Philippe Gerum wrote: > Jan Kiszka wrote: >> Hi, >> >> while I originally only wanted to add timer abstraction to RTDM, I now >> have patch series for xntimer pending on my box pushing this layer >> closer to hrtimer. >> >> But before posting it for discussion (needs further testing anyway), I >> have two questions regarding some minor though not totally uninteresting >> optimisation possibilities: >> >> 1. Is calling xntimer_start() with value=XN_INFINITE a real use case? >>It's not documented explicitly. The effect of such an invocation >>looks a bit like xntimer_stop(), but I didn't find a real caller so >>far to asses it's relevance. > > xnpod_start_timer() uses this property to start the host tick relay > timer. If XNARCH_HOST_TICK is zero, then no relay is required, and the > timer should remain passive. I see, but there is likely some other way to achieve this. The point I'm having in mind is heavy usage of xntimer_start, e.g. from inside some timer handler. RTnet could become such a user one day when we may migrate the TDMA scheduler from thread context to a timer handler. > >> >>If it is not used and could rather be declared illegal, we could safe >>the related code in the do_timer_start handlers. >> > > Dunno. To do that, we would need to carefully inspect each and every > caller, especially for the various skins, which implies to analyze the > requirements of the mimicked API too. For sure, but we will have to review and test some stuff anyway with my patches. :) > >> 2. rthal_timer_program_shot() uses explicit rthal_local_irq_save_hw on >>ia64 and i386. Given the head optimisation, IRQs should already be >>disabled when calling this service. So, can this IRQ masking be made >>depending on !CONFIG_XENO_OPT_PIPELINE_HEAD? >> > > Yes. Ok, will get integrated. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] timer optimisations
Jan Kiszka wrote: Hi, while I originally only wanted to add timer abstraction to RTDM, I now have patch series for xntimer pending on my box pushing this layer closer to hrtimer. But before posting it for discussion (needs further testing anyway), I have two questions regarding some minor though not totally uninteresting optimisation possibilities: 1. Is calling xntimer_start() with value=XN_INFINITE a real use case? It's not documented explicitly. The effect of such an invocation looks a bit like xntimer_stop(), but I didn't find a real caller so far to asses it's relevance. xnpod_start_timer() uses this property to start the host tick relay timer. If XNARCH_HOST_TICK is zero, then no relay is required, and the timer should remain passive. If it is not used and could rather be declared illegal, we could safe the related code in the do_timer_start handlers. Dunno. To do that, we would need to carefully inspect each and every caller, especially for the various skins, which implies to analyze the requirements of the mimicked API too. 2. rthal_timer_program_shot() uses explicit rthal_local_irq_save_hw on ia64 and i386. Given the head optimisation, IRQs should already be disabled when calling this service. So, can this IRQ masking be made depending on !CONFIG_XENO_OPT_PIPELINE_HEAD? Yes. ARM uses an additional lock as well, but it's hidden inside the ipipe patch and is likely required to remain independent of the caller's properties. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
