From: Florian Bezdeka <florian.bezdeka@siemens.com>
To: xenomai@lists.linux.dev
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Clara Kowalsky <clara.kowalsky@siemens.com>
Subject: Problem with rt_task_set_affinity() in combination with xenomai.supported_cpus
Date: Tue, 09 Apr 2024 13:56:23 +0200 [thread overview]
Message-ID: <2fc736948068580213268be9548154799b5c8633.camel@siemens.com> (raw)
Hi all,
while looking into recent bug reports we were facing a situation where
we were seeing completely different behavior of provided test
applications / reproducers than the original reporter.
It turned out that reproducers were assuming that specific CPUs are
allowed to run Xenomai applications, which was not the case. The
cmdline parameter xenomai.supported_cpus=0x3 (= allow the first 2 CPUs
to serve RT tasks) was used here to shrink the set of CPUs that are
allowed to run RT tasks.
Example (out of my head), error handling ignored:
void rt_main(void *arg)
{
// do RT stuff
}
main()
{
RT_TASK demo_task;
cpu_set_t mask;
int ret;
CPU_ZERO(&mask);
CPU_SET(3, &mask); // Assumption: CPU 3 is allowed to run
// RT tasks
rt_task_create(&demo_task, "demo", 0, 50, 0);
rt_task_set_affinity(&demo_task, &mask);
rt_task_start(&demo_task, &rt_main, 0);
}
rt_task_set_affinity() does not report any error in case the supplied
CPU mask is "invalid" in terms of "there is no usable CPU available".
If an invalid affinity was set rt_task_start() will block forever.
How should the application know that the affinity is invalid?
My current understanding is that the there is no hook (provided by
dovetail) that would allow intersecting the sched_setaffinity() call
that is used at the end.
Should we implement such a hook? Is there something that I missed?
Best regards,
Florian
next reply other threads:[~2024-04-09 11:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 11:56 Florian Bezdeka [this message]
2024-04-09 17:13 ` Problem with rt_task_set_affinity() in combination with xenomai.supported_cpus Jan Kiszka
2024-04-10 10:09 ` Florian Bezdeka
2024-04-10 10:49 ` Jan Kiszka
2024-04-10 11:37 ` Florian Bezdeka
2024-04-10 11:59 ` Florian Bezdeka
2024-04-10 13:57 ` Jan Kiszka
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=2fc736948068580213268be9548154799b5c8633.camel@siemens.com \
--to=florian.bezdeka@siemens.com \
--cc=clara.kowalsky@siemens.com \
--cc=jan.kiszka@siemens.com \
--cc=xenomai@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).