From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Xenomai <xenomai@lists.linux.dev>
Subject: Re: SCHED_SPORADIC in Xenomai 3
Date: Thu, 11 Jun 2026 09:56:52 +0200 [thread overview]
Message-ID: <87se6tbjcr.fsf@xenomai.org> (raw)
In-Reply-To: <2460b105-370d-4cf5-8cb6-e40809763cd3@siemens.com> (Jan Kiszka's message of "Thu, 11 Jun 2026 09:42:51 +0200")
Jan Kiszka <jan.kiszka@siemens.com> writes:
> On 11.06.26 09:33, Philippe Gerum wrote:
>>
>> Hi Jan,
>>
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>
>>> Hi Philippe,
>>>
>>> while trying to port the signal-while-suspended fix to Xenomai 3, I ran
>>> into XNHELD, a state only existing there. I suppose that was once
>>> forward-ported as EVL_T_HALT. The only user of XNHELD in Xenomai 3 is
>>> SCHED_SPORADIC - so let's dive into that scheduling class.
>>>
>>> Turned out it was never documented, not even linked to the POSIX
>>> standard. But it also slightly differs from it (low_prio = -1 -> suspend
>>> on depletion). There is also no test case, so I asked an AI for one.
>>> That worked fairly well as it seems to have revealed an issue:
>>>
>>> Could it be that we are not properly suspending the budget tracking when
>>> a higher-prio task from a different scheduling class is preempting a
>>> sporadic thread? It looks like that xnsched_sporadic_pick is not invoked
>>> if a thread is selected from a higher-prio class first, namely sched-rt
>>> with its weight 4 vs. 3 if sched-sporadic. Or is that an (undocumented)
>>> limitation/misconfiguration? Is that issue even affecting other
>>> time-slicing classes as well??
>>
>> Yes, this is a systemic bug. We need to tell classes that some thread of
>> theirs is scheduling out.
>>
>
> OK, then please have a look of my proposal from today. If it makes
> sense, I'm happy to submit it for x3 as well as linux-evl patch.
>
>>>
>>> That furthermore makes me wonder if we actually have users of
>>> sched-sporadic. Likely a hard to answer question, as usual. But such a
>>> limitation should have been observed earlier under real workload...
>>>
>>
>> I only know of one user, back in 2009. Never received any feedback since
>> then.
>>
>
> Hmm, I'm inclined to retire it then.
The sched sporadic implementation is certainly not quite right ATM in
x3, although it could be fixed. This said, the POSIX standard was even
originally broken IIRC and required some amendments. I did not port that
sched class to x4.
--
Philippe.
prev parent reply other threads:[~2026-06-11 7:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 6:24 SCHED_SPORADIC in Xenomai 3 Jan Kiszka
2026-06-10 7:21 ` Jan Kiszka
2026-06-10 7:33 ` Jan Kiszka
2026-06-10 18:17 ` Jan Kiszka
2026-06-11 5:38 ` Jan Kiszka
2026-06-11 7:49 ` Philippe Gerum
2026-06-11 7:56 ` Jan Kiszka
2026-06-11 8:53 ` Philippe Gerum
2026-06-11 7:36 ` Philippe Gerum
2026-06-11 7:33 ` Philippe Gerum
2026-06-11 7:42 ` Jan Kiszka
2026-06-11 7:56 ` Philippe Gerum [this message]
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=87se6tbjcr.fsf@xenomai.org \
--to=rpm@xenomai.org \
--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 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.