[Xenomai-help] ARM interrupt latency

[Xenomai-help] ARM interrupt latency

[Daniel Jacques (Alten)]

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

Hi all,

 

I am using xenomai 2.3.4 on a product based on ARM1136.

- I create several interrupt objects using "rt_intr_create" routine from user-space and their associated interrupt tasks that permanently wait for interrupt using "rt_intr_wait" routine.

- The application contains also several user tasks to manage specific functionalities.

- The processing in the interrupt tasks is very short: typically only resume the user task.

 

By adding some embedded spies, I notice high latencies between interrupt task and user task (maximum 300µs, average 100µs).

If I supposed inherent interrupt latency on ARM is around 30µs, I can explain the latency between interrupt task and user task by the important number of interrupts on my system (around 100 IRQ are generated in each period of 20ms). It means than only 5 or 6 IRQ at the same time can produced this effect ...

 

So, first I'd like to have your opinion on this interpretation ...

And in a second step, do you think that It could be interesting and especially sufficient in term of performance, to directly manage interrupt in kernel space instead of user space?

Additionally, if I choose this solution, should I publish the source code (as kernel and xenomai are under GPL)?

 

Thanks in advance

 

Jacques


[-- Attachment #2: Type: text/html, Size: 4602 bytes --]

Re: [Xenomai-help] ARM interrupt latency

[Gilles Chanteperdrix]

Daniel Jacques (Alten) wrote:
> Hi all,
> 
> 
> 
> I am using xenomai 2.3.4 on a product based on ARM1136.
> 
> - I create several interrupt objects using "rt_intr_create" routine
> from user-space and their associated interrupt tasks that permanently
> wait for interrupt using "rt_intr_wait" routine.
> 
> - The application contains also several user tasks to manage specific
> functionalities.
> 
> - The processing in the interrupt tasks is very short: typically only
> resume the user task.
> 
> 
> 
> By adding some embedded spies, I notice high latencies between
> interrupt task and user task (maximum 300µs, average 100µs).
> 
> If I supposed inherent interrupt latency on ARM is around 30µs, I can
> explain the latency between interrupt task and user task by the
> important number of interrupts on my system (around 100 IRQ are
> generated in each period of 20ms). It means than only 5 or 6 IRQ at
> the same time can produced this effect ...

No the latency between interrupt and user task is due to the worst time
taken by a user-space context switch which, among other things contains
a full cache flush if you are using a VIVT cache. So, 300us is expected,
 especially with Xenomai 2.3.4, which does not contain any of the
optimizations which have been done in this area. I think 30us is overly
optimistic too, interrupt latency is probably more around 50us.

In any case, Xenomai ships with a tool called "latency" which will help
you find the latency of your system. Actually, the first thing you
should do when testing Xenomai on a platform is run the latency test to
get the figures of Xenomai on your platform.


> 
> 
> 
> So, first I'd like to have your opinion on this interpretation ...
> 
> And in a second step, do you think that It could be interesting and
> especially sufficient in term of performance, to directly manage
> interrupt in kernel space instead of user space?

Yes, managing interrupt in kernel-space is not only good for latencies,
it is good for design. By forcing you to split your code between driver
code and user application, it will help you write future proof code,
instead of spaghetti code with driver and application intermixed.

> 
> Additionally, if I choose this solution, should I publish the source
> code (as kernel and xenomai are under GPL)?

Well, under the terms of the GPL, anyone you distribute your system to
should have a way to get the sources, yes.

-- 
                                                 Gilles.

Re: [Xenomai-help] ARM interrupt latency

[Daniel Jacques (Alten)]

Thanks lot for your help and recommendation.
I will keep you up to date on my investigation,
Regards,
Jacques

Jacques DANIEL - Consultant ALTEN
Grass Valley - France
Rue du Clos Courtel
35517 Cesson Sévigné Cedex
33 (0)2 99 27 38 38
 
 Pensez à l'environnement avant d'imprimer ce mail / Please consider the environment before printing
 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: mardi 28 avril 2009 19:00
To: Daniel Jacques (Alten)
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] ARM interrupt latency

Daniel Jacques (Alten) wrote:
> Hi all,
> 
> 
> 
> I am using xenomai 2.3.4 on a product based on ARM1136.
> 
> - I create several interrupt objects using "rt_intr_create" routine
> from user-space and their associated interrupt tasks that permanently
> wait for interrupt using "rt_intr_wait" routine.
> 
> - The application contains also several user tasks to manage specific
> functionalities.
> 
> - The processing in the interrupt tasks is very short: typically only
> resume the user task.
> 
> 
> 
> By adding some embedded spies, I notice high latencies between
> interrupt task and user task (maximum 300µs, average 100µs).
> 
> If I supposed inherent interrupt latency on ARM is around 30µs, I can
> explain the latency between interrupt task and user task by the
> important number of interrupts on my system (around 100 IRQ are
> generated in each period of 20ms). It means than only 5 or 6 IRQ at
> the same time can produced this effect ...

No the latency between interrupt and user task is due to the worst time
taken by a user-space context switch which, among other things contains
a full cache flush if you are using a VIVT cache. So, 300us is expected,
 especially with Xenomai 2.3.4, which does not contain any of the
optimizations which have been done in this area. I think 30us is overly
optimistic too, interrupt latency is probably more around 50us.

In any case, Xenomai ships with a tool called "latency" which will help
you find the latency of your system. Actually, the first thing you
should do when testing Xenomai on a platform is run the latency test to
get the figures of Xenomai on your platform.


> 
> 
> 
> So, first I'd like to have your opinion on this interpretation ...
> 
> And in a second step, do you think that It could be interesting and
> especially sufficient in term of performance, to directly manage
> interrupt in kernel space instead of user space?

Yes, managing interrupt in kernel-space is not only good for latencies,
it is good for design. By forcing you to split your code between driver
code and user application, it will help you write future proof code,
instead of spaghetti code with driver and application intermixed.

> 
> Additionally, if I choose this solution, should I publish the source
> code (as kernel and xenomai are under GPL)?

Well, under the terms of the GPL, anyone you distribute your system to
should have a way to get the sources, yes.

-- 
                                                 Gilles.