timer_create affinity

timer_create affinity

[Nicolae Rosia]

Hello,

I'm working on a real-time application using POSIX timers running on a
QorIQ PowerPC platform with a 4.1 PREEMPT RT kernel and I'm trying to
understand whether the following can happen:
1. A thread with a core affinity #0 creates a timer which will invoke
a callback.
2. The kernel will setup the timer using a local timer running on a
different core, core #1
3. The ISR will fire, and could be dispatched by core #2
4. The scheduler will run the callback on core #3.

Is there a way to make sure this whole chain will be executed on a
single core, the core of the caller?

Best regards,
Nicolae Rosia

Re: timer_create affinity

[John Ogness]

On 2017-05-25, Nicolae Rosia <nicolae.rosia.oss@gmail.com> wrote:
> I'm working on a real-time application using POSIX timers running on a
> QorIQ PowerPC platform with a 4.1 PREEMPT RT kernel and I'm trying to
> understand whether the following can happen:
>
> 1. A thread with a core affinity #0 creates a timer which will invoke
> a callback.
> 2. The kernel will setup the timer using a local timer running on a
> different core, core #1
> 3. The ISR will fire, and could be dispatched by core #2
> 4. The scheduler will run the callback on core #3.
>
> Is there a way to make sure this whole chain will be executed on a
> single core, the core of the caller?

Avoid POSIX timers if you can. POSIX timers not only have the issue that
you mentioned, but also are generally bad for realtime applications.

The realtime wiki has an example[0] of running a cyclic task. With that
simple example you have complete control over the context of your
task. This is necessary to avoid things like priority inversion and
page-faults, and gives you control over things like affinity or cgroups.

John Ogness

[0] https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic