Re: [Xenomai] Performance impact after switching from 2.6.2.1 to 2.6.4

[Philippe Gerum <rpm@xenomai.org>]

On 06/07/2016 04:13 PM, Wolfgang Netbal wrote:

> As I wrote above, I get interrupts 1037 handled by rthal_apc_handler()
> and 1038 handled by xnpod_schedule_handler() while my realtime task
> is running on kernel 3.10.53 with Xenomai 2.6.4.
> On kernel 3.0.43 with Xenomai 2.6.4 there are no interrupts, except the
> once that are send by my board using GPIOs, but this virtual interrupts
> are assigned to Xenomai and Linux as well but I didn't see a handler
> installed.
> I'm pretty sure that these interrupts are slowing down my system, but
> where do they come from ?
> why didn't I see them on Kernel 3.0.43 with Xenomai 2.6.4 ?
> how long do they need to process ?
> 
> Is there any dependecy in Xenomai between the kernel version and this
> virtual interrupts ?
> 

Maybe you should consider reading all the replies you get:

On 05/31/2016 05:08 PM, Philippe Gerum wrote:
> On 05/31/2016 04:09 PM, Wolfgang Netbal wrote:
>> Dear all,
>>
>> we have moved our application from "XENOMAI 2.6.2.1 + Linux 3.0.43" to
>> "XENOMAI 2.6.4. + Linux 3.10.53". Our target is an i.MX6DL. The system
>> is now up and running and works stable. Unfortunately we see a
>> difference in the performance. Our old combination (XENOMAI 2.6.2.1 +
>> Linux 3.0.43) was slightly faster.
>>
>
> Could you quantify "slightly faster"? This is a dual kernel system, so
> changes on either the regular kernel side and/or the co-kernel side may
> have a measurable impact.
>
>> At the moment it looks like that XENOMAI 2.6.4 calls
>> xnpod_schedule_handler much more often then XENOMAI 2.6.2.1 in our old
>> system.  Every call of xnpod_schedule_handler interrupts our main
>> XENOMAI task with priority = 95.
>
> That handler is attached to the inter-processor interrupt used for
> rescheduling tasks running on a remote CPU. You may want to check the
> CPU affinity settings of your tasks, and the way they
interact/synchronize.
>

You may also want to check the mode switch count for your threads in
/proc/xenomai/stat (MSW field). I suspect your application may be
switching mode like crazy between Linux and Xenomai, causing interrupt
activity for waking up either sides in turn.

-- 
Philippe.