Re: [Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> If shadowed Linux tasks with SCHED_RR policy change their priority,
>> do_setsched_event currenty ignores this. Extend the condition to catch
>> this case as well.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>> ---
>>
>>  ksrc/nucleus/shadow.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index bd3bb3d..9f81c32 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -2312,7 +2312,7 @@ static inline void do_setsched_event(struct task_struct *p, int priority)
>>  	union xnsched_policy_param param;
>>  	struct xnsched *sched;
>>  
>> -	if (!thread || p->policy != SCHED_FIFO)
>> +	if (!thread || (p->policy != SCHED_FIFO && p->policy != SCHED_RR))
>>  		return;
> 
> After some thinking about it, I think this is the wrong way to go. When
> the user-space requests SCHED_RR, only the shadow should use SCHED_RR,
> the linux thread should keep using SCHED_FIFO. We do not want two
> schedulers to do round-robin, this would result in unpredictable behaviour.

Well, passing SCHED_FIFO instead of SCHED_RR to glibc is one thing. But
as you can't enforce this mapping anyway, I don't think it is wrong to
accept also prio changes of SCHED_RR shadow threads.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux