Re: [PATCH] Allow changing CPU affinity of RT kernel tasks

[Richard Weinberger <richard@sigma-star.at>]

On Montag, 26. Jänner 2026 17:26 Jan Kiszka wrote:
> On 26.01.26 16:11, Richard Weinberger wrote:
> > On Montag, 26. Jänner 2026 15:28 'Jan Kiszka' via upstream wrote:
> >> This is one issue with setting the affinity "from outside",
> >> asynchronously. The other is that it will always imply a migration of
> >> the kernel task, thus a phase of non-RT. If someone forgets about this
> >> and sets the affinity at the wrong time, it can ruin RT workloads.
> > 
> > I assumed this is known and expected since changing the CPU affinity of userspace
> > tasks as the same implications.
> > 
> 
> Likely true. EINTR can be a topic with some calls there as well, and
> some applications may just bail out (or because of trapping SIGDEBUG).

Yes. I did more investigation. sched_setaffinity() causes always two domain
switches but cobalt syscalls get restarted automatically due to SA_RESTART
of the SIGSHADOW handler.

> >> This tuning gap for RTDM task is rather old. I was already considering
> >> to add an explicit affinity API to RTDM to set this from the driver.
> >> That would allow to set the affinity early, right after task creation
> >> and before the driver signals it is ready. Risk of such an interface is
> >> that people start to hard-code the affinity into the drivers, rather
> >> than making it configurable to userspace.
> > 
> > Well, the goal of my patch is improving the situation to match userspace
> > semantics.
> > People expect that sched_setaffinity() kinda works.
> 
> At least "taskset" (script-based tuning) - we do not have an API for
> userspace to retrieve the PID of a RTDM task. Yeah, there is some truth
> in this.

For scripts /proc/xenomai/sched/stat should work just fine.
In my tests I'm always using it together with taskset.

Do you have a new cobalt syscall in mind to query the RTDM pid?
 
> So we have the following issues still to consider when adding this
> capability:
> 
>  - Driver supporting external tuning need to handle EINTR from
>    relevant blocking calls - others will fail, and that is fine.

The in-tree drivers needs only minimal changes from what I can tell.

>  - Affinity tuning by userspace should be done while the kernel thread
>    is (still) "idle" - identifying this remains driver-specific. Maybe
>    document this in rtdm_task_init?

Yes, I'll happily document this.

>  - Should we also provide a RTDM API that maps an RTDM task on
>    set_cpus_allowed* or at least officially provide the task_struct for
>    some rtdm_task_t? rtdm_task_t is opaque, xnthread_host_task is
>    internal from RTDM-perspective.

What use cases do you have in mind?

Beside of that, I have also a patch in the pipline which adds a new parameter
to rtdm_task_init() to specify the target CPU instead of CPU_MASK_ALL.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y