[Xenomai-core] timer optimisations

[Xenomai-core] timer optimisations

[Jan Kiszka]

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

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.

   If it is not used and could rather be declared illegal, we could safe
   the related code in the do_timer_start handlers.

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?

   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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] timer optimisations

[Philippe Gerum]

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] timer optimisations

[Jan Kiszka]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]