Re: SCHED_SPORADIC in Xenomai 3

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 11.06.26 09:49, Philippe Gerum wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> diff --git a/kernel/cobalt/sched.c b/kernel/cobalt/sched.c
>>> index d527b6be2c..6dfbf83220 100644
>>> --- a/kernel/cobalt/sched.c
>>> +++ b/kernel/cobalt/sched.c
>>> @@ -895,6 +895,7 @@ static inline void do_lazy_user_work(struct xnthread *curr)
>>>  
>>>  int ___xnsched_run(struct xnsched *sched)
>>>  {
>>> +	struct xnsched_class *prev_schedclass __maybe_unused;
>>>  	bool switched = false, leaving_inband;
>>>  	struct xnthread *prev, *next, *curr;
>>>  	spl_t s;
>>> @@ -933,6 +934,13 @@ int ___xnsched_run(struct xnsched *sched)
>>>  
>>>  	prev = curr;
>>>  
>>> +#ifdef CONFIG_XENO_OPT_SCHED_CLASSES
>>> +	prev_schedclass = prev->sched_class;
>>> +	if (prev_schedclass->weight < next->sched_class->weight &&
>>> +	    prev_schedclass->sched_out)
>>> +		prev_schedclass->sched_out(prev);
>>> +#endif
>> 
>> I would call the scheduling out hook unconditionally, the sched class
>> has all the information required to sort this out, do the right thing,
>> which the generic scheduler does not.
>
> That would mean moving the accounting out of the pick callback
> unconditionally as well - leaving some smaller synergies on the road.

This hook would have to be called when the current thread blocks, which
should not be filtered out by the class weight check. Moreover, if next
!= curr, we know for sure that curr is either blocked, yields on a
round-robin tick or gets preempted on priority basis. In the latter
case, the sched class weight is accounted for when picking next. If
current is still runnable, prev_schedclass->weight has to be lower than
next->sched_class->weight for preemption to take place anyway.

IOW, the following change would be appropriate:

>>> +	    if (prev_schedclass->sched_out)
>>> +		prev_schedclass->sched_out(prev);

-- 
Philippe.