[Xenomai] RTDM device driver interrupts over primary mode task?

[Xenomai] RTDM device driver interrupts over primary mode task?

[Steve B]

Hello,

Is it possible that my hardware interrupts tied to RTDM device drivers are
able to pre-empt my high priority task running in primary mode, or do the
interrupts get serviced after the task yields the CPU?

Thanks,

Steve

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Philippe Gerum]

On 03/04/2015 05:59 PM, Steve B wrote:
> Hello,
> 
> Is it possible that my hardware interrupts tied to RTDM device drivers are
> able to pre-empt my high priority task running in primary mode, or do the
> interrupts get serviced after the task yields the CPU?
> 

If taken by the CPU, IRQs hooked by a RTDM driver will preempt any
real-time task code immediately (in kernel or userland). IRQs hooked by
regular kernel drivers will be postponed until all rt activity has
completed on the receiving CPU.

-- 
Philippe.

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Steve B]

On Wed, Mar 4, 2015 at 9:25 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/04/2015 05:59 PM, Steve B wrote:
> > Hello,
> >
> > Is it possible that my hardware interrupts tied to RTDM device drivers
> are
> > able to pre-empt my high priority task running in primary mode, or do the
> > interrupts get serviced after the task yields the CPU?
> >
>
> If taken by the CPU, IRQs hooked by a RTDM driver will preempt any
> real-time task code immediately (in kernel or userland). IRQs hooked by
> regular kernel drivers will be postponed until all rt activity has
> completed on the receiving CPU.
>
> --
> Philippe.
>

A follow-up question. When this happens, does the execution return to the
primary-mode task that was running at the time the IRQ was received, or
does the scheduler let other runnable tasks have a shot at the CPU at that
time?

Steve

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Philippe Gerum]

On 03/09/2015 07:18 PM, Steve B wrote:
> 
> 
> On Wed, Mar 4, 2015 at 9:25 AM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
>     On 03/04/2015 05:59 PM, Steve B wrote:
>     > Hello,
>     >
>     > Is it possible that my hardware interrupts tied to RTDM device
>     drivers are
>     > able to pre-empt my high priority task running in primary mode, or
>     do the
>     > interrupts get serviced after the task yields the CPU?
>     >
> 
>     If taken by the CPU, IRQs hooked by a RTDM driver will preempt any
>     real-time task code immediately (in kernel or userland). IRQs hooked by
>     regular kernel drivers will be postponed until all rt activity has
>     completed on the receiving CPU.
> 
>     --
>     Philippe.
> 
> 
> A follow-up question. When this happens, does the execution return to
> the primary-mode task that was running at the time the IRQ was received,
> or does the scheduler let other runnable tasks have a shot at the CPU at
> that time?

This return path is an opportunity for the real-time core to switch to a
thread with higher priority that might have been resumed by the handler.
Otherwise, the preempted thread resumes execution.

The priority rule enforced can be expressed as: "at any point in time,
the oldest runnable thread from the highest priority level shall run".

-- 
Philippe.

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Steve B]

On Tue, Mar 10, 2015 at 2:59 PM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/09/2015 07:18 PM, Steve B wrote:
> >
> >
> > On Wed, Mar 4, 2015 at 9:25 AM, Philippe Gerum <rpm@xenomai.org
> > <mailto:rpm@xenomai.org>> wrote:
> >
> >     On 03/04/2015 05:59 PM, Steve B wrote:
> >     > Hello,
> >     >
> >     > Is it possible that my hardware interrupts tied to RTDM device
> >     drivers are
> >     > able to pre-empt my high priority task running in primary mode, or
> >     do the
> >     > interrupts get serviced after the task yields the CPU?
> >     >
> >
> >     If taken by the CPU, IRQs hooked by a RTDM driver will preempt any
> >     real-time task code immediately (in kernel or userland). IRQs hooked
> by
> >     regular kernel drivers will be postponed until all rt activity has
> >     completed on the receiving CPU.
> >
> >     --
> >     Philippe.
> >
> >
> > A follow-up question. When this happens, does the execution return to
> > the primary-mode task that was running at the time the IRQ was received,
> > or does the scheduler let other runnable tasks have a shot at the CPU at
> > that time?
>
> This return path is an opportunity for the real-time core to switch to a
> thread with higher priority that might have been resumed by the handler.
> Otherwise, the preempted thread resumes execution.
>
> The priority rule enforced can be expressed as: "at any point in time,
> the oldest runnable thread from the highest priority level shall run".
>
> --
> Philippe.
>

Thanks, makes sense! I was having an issue where my highest priority thread
was having occasional overruns, and just trying to cover all my bases.
There are a few threads of equal priority but none higher, and none of them
should take as long as the overruns that I'm having. In the meantime I also
found that I still get the overruns if I find a way to feed spoofed data to
the main work thread without the hardware/peripherals generating those
interrupts, so I think I've pinned it down to being something in that
thread itself.

Cheers,

Steve

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Philippe Gerum]

On 03/11/2015 03:22 AM, Steve B wrote:
> 
> 
> On Tue, Mar 10, 2015 at 2:59 PM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>> wrote:
> 
>     On 03/09/2015 07:18 PM, Steve B wrote:
>     >
>     >
>     > On Wed, Mar 4, 2015 at 9:25 AM, Philippe Gerum <rpm@xenomai.org <mailto:rpm@xenomai.org>
>     > <mailto:rpm@xenomai.org <mailto:rpm@xenomai.org>>> wrote:
>     >
>     >     On 03/04/2015 05:59 PM, Steve B wrote:
>     >     > Hello,
>     >     >
>     >     > Is it possible that my hardware interrupts tied to RTDM device
>     >     drivers are
>     >     > able to pre-empt my high priority task running in primary
>     mode, or
>     >     do the
>     >     > interrupts get serviced after the task yields the CPU?
>     >     >
>     >
>     >     If taken by the CPU, IRQs hooked by a RTDM driver will preempt any
>     >     real-time task code immediately (in kernel or userland). IRQs
>     hooked by
>     >     regular kernel drivers will be postponed until all rt activity has
>     >     completed on the receiving CPU.
>     >
>     >     --
>     >     Philippe.
>     >
>     >
>     > A follow-up question. When this happens, does the execution return to
>     > the primary-mode task that was running at the time the IRQ was
>     received,
>     > or does the scheduler let other runnable tasks have a shot at the
>     CPU at
>     > that time?
> 
>     This return path is an opportunity for the real-time core to switch to a
>     thread with higher priority that might have been resumed by the handler.
>     Otherwise, the preempted thread resumes execution.
> 
>     The priority rule enforced can be expressed as: "at any point in time,
>     the oldest runnable thread from the highest priority level shall run".
> 
>     --
>     Philippe.
> 
> 
> Thanks, makes sense! I was having an issue where my highest priority
> thread was having occasional overruns, and just trying to cover all my
> bases. There are a few threads of equal priority but none higher, and
> none of them should take as long as the overruns that I'm having. In the
> meantime I also found that I still get the overruns if I find a way to
> feed spoofed data to the main work thread without the
> hardware/peripherals generating those interrupts, so I think I've pinned
> it down to being something in that thread itself.
> 

You may want to have a look at /proc/xenomai/stat (or xenomai/sched/stat
with 3.x), column MSW, when your application runs, to make sure the
worker thread is not unexpectedly switching to relaxed/secondary mode,
which would definitely cause some delays.

-- 
Philippe.

Re: [Xenomai] RTDM device driver interrupts over primary mode task?

[Steve B]

On Wed, Mar 11, 2015 at 12:09 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/11/2015 03:22 AM, Steve B wrote:
> >
> >
> > On Tue, Mar 10, 2015 at 2:59 PM, Philippe Gerum <rpm@xenomai.org
> > <mailto:rpm@xenomai.org>> wrote:
> >
> >     On 03/09/2015 07:18 PM, Steve B wrote:
> >     >
> >     >
> >     > On Wed, Mar 4, 2015 at 9:25 AM, Philippe Gerum <rpm@xenomai.org
> <mailto:rpm@xenomai.org>
> >     > <mailto:rpm@xenomai.org <mailto:rpm@xenomai.org>>> wrote:
> >     >
> >     >     On 03/04/2015 05:59 PM, Steve B wrote:
> >     >     > Hello,
> >     >     >
> >     >     > Is it possible that my hardware interrupts tied to RTDM
> device
> >     >     drivers are
> >     >     > able to pre-empt my high priority task running in primary
> >     mode, or
> >     >     do the
> >     >     > interrupts get serviced after the task yields the CPU?
> >     >     >
> >     >
> >     >     If taken by the CPU, IRQs hooked by a RTDM driver will preempt
> any
> >     >     real-time task code immediately (in kernel or userland). IRQs
> >     hooked by
> >     >     regular kernel drivers will be postponed until all rt activity
> has
> >     >     completed on the receiving CPU.
> >     >
> >     >     --
> >     >     Philippe.
> >     >
> >     >
> >     > A follow-up question. When this happens, does the execution return
> to
> >     > the primary-mode task that was running at the time the IRQ was
> >     received,
> >     > or does the scheduler let other runnable tasks have a shot at the
> >     CPU at
> >     > that time?
> >
> >     This return path is an opportunity for the real-time core to switch
> to a
> >     thread with higher priority that might have been resumed by the
> handler.
> >     Otherwise, the preempted thread resumes execution.
> >
> >     The priority rule enforced can be expressed as: "at any point in
> time,
> >     the oldest runnable thread from the highest priority level shall
> run".
> >
> >     --
> >     Philippe.
> >
> >
> > Thanks, makes sense! I was having an issue where my highest priority
> > thread was having occasional overruns, and just trying to cover all my
> > bases. There are a few threads of equal priority but none higher, and
> > none of them should take as long as the overruns that I'm having. In the
> > meantime I also found that I still get the overruns if I find a way to
> > feed spoofed data to the main work thread without the
> > hardware/peripherals generating those interrupts, so I think I've pinned
> > it down to being something in that thread itself.
> >
>
> You may want to have a look at /proc/xenomai/stat (or xenomai/sched/stat
> with 3.x), column MSW, when your application runs, to make sure the
> worker thread is not unexpectedly switching to relaxed/secondary mode,
> which would definitely cause some delays.
>
> --
> Philippe.
>

Yes, I did see that I eliminated switches to secondary mode in any of my
tasks (there are a couple at the beginning but no increments in normal
operation), so I was wondering if there was anything at all that could
still be pre-empting that task.
We are using some auto-generated code, and I have actually found that one
of the math functions is going haywire and taking hundreds of microseconds
in some cases so I'm pretty sure that's my culprit!

Steve