From: Richard Weinberger <richard@sigma-star.at>
To: Richard Weinberger <richard@nod.at>,
xenomai@xenomai.org, upstream+xenomai@sigma-star.at
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH] Allow changing CPU affinity of RT kernel tasks
Date: Mon, 26 Jan 2026 16:11:46 +0100 [thread overview]
Message-ID: <3016173.h6DGQjDypG@nailgun> (raw)
In-Reply-To: <29de15c3-4d96-4194-9cbf-c362e9e83698@siemens.com>
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.
> 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.
Thanks,
//richard
--
sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y
next prev parent reply other threads:[~2026-01-26 15:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 12:57 [PATCH] Allow changing CPU affinity of RT kernel tasks Richard Weinberger
2026-01-26 14:28 ` Jan Kiszka
2026-01-26 15:11 ` Richard Weinberger [this message]
2026-01-26 16:26 ` Jan Kiszka
2026-01-26 22:05 ` Richard Weinberger
2026-01-27 6:15 ` Jan Kiszka
2026-01-26 15:50 ` Florian Bezdeka
2026-01-26 16:04 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3016173.h6DGQjDypG@nailgun \
--to=richard@sigma-star.at \
--cc=jan.kiszka@siemens.com \
--cc=richard@nod.at \
--cc=upstream+xenomai@sigma-star.at \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.