[Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Jan Kiszka]

Hi,

unfortunately I'm forced to switch to other bugs, but I found out a bit
more about the issue that pthread_getschedparam doesn't return the
correct policy&prio under trunk - at least when called from threads
created via pthread_create as SCHED_FIFO:

Such threads start with SCHED_OTHER, but then the propagation via
do_setsched_event and finally xnsched_set_policy only seems to affect
thread.cprio, not bprio. Will see if I can continue debugging this
later, but maybe /someone/ already knows what goes wrong...

Thanks,
Jan

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

Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Hi,
> 
> unfortunately I'm forced to switch to other bugs, but I found out a bit
> more about the issue that pthread_getschedparam doesn't return the
> correct policy&prio under trunk - at least when called from threads
> created via pthread_create as SCHED_FIFO:
> 
> Such threads start with SCHED_OTHER, but then the propagation via
> do_setsched_event and finally xnsched_set_policy only seems to affect
> thread.cprio, not bprio. Will see if I can continue debugging this
> later, but maybe /someone/ already knows what goes wrong...

Yes, pthread_getschedparam returns the priority in the glibc cache. And
this one may not be in sync with the priority known by the kernel(s).
However, this is supposed to be fixed by calling
__real_pthread_setschedparam in various key places.

-- 
                                                 Gilles.

Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> unfortunately I'm forced to switch to other bugs, but I found out a bit
>> more about the issue that pthread_getschedparam doesn't return the
>> correct policy&prio under trunk - at least when called from threads
>> created via pthread_create as SCHED_FIFO:
>>
>> Such threads start with SCHED_OTHER, but then the propagation via
>> do_setsched_event and finally xnsched_set_policy only seems to affect
>> thread.cprio, not bprio. Will see if I can continue debugging this
>> later, but maybe /someone/ already knows what goes wrong...
> 
> Yes, pthread_getschedparam returns the priority in the glibc cache. And

__wrap_pthread_getschedparam calls into the kernel.

> this one may not be in sync with the priority known by the kernel(s).
> However, this is supposed to be fixed by calling
> __real_pthread_setschedparam in various key places.

This is already called - on thread creation. I'm not debugging
prio/policy adjustment during thread lifetime, already the initial
values passed to pthread_create are not properly reflected by
pthread_getschedparam because bprio is wrong (BTW, /proc/xenomai/sched
should probably better return both cprio and bprio, not just cprio).

Jan

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

Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Philippe Gerum]

Jan Kiszka wrote:
> Hi,
> 
> unfortunately I'm forced to switch to other bugs, but I found out a bit
> more about the issue that pthread_getschedparam doesn't return the
> correct policy&prio under trunk - at least when called from threads
> created via pthread_create as SCHED_FIFO:
> 
> Such threads start with SCHED_OTHER, but then the propagation via
> do_setsched_event and finally xnsched_set_policy only seems to affect
> thread.cprio, not bprio. Will see if I can continue debugging this
> later, but maybe /someone/ already knows what goes wrong...
> 

With the new scheduler infrastructure, ->bprio tends to be used solely as a
priority backup area when dealing with PIP; but at the same time, some skins
still consider it as an always up-to-date location where to find the nominal
priority of a thread, so this hunk should help in keeping things compatible with
2.4.x:

diff --git a/ksrc/nucleus/sched.c b/ksrc/nucleus/sched.c
index 8d50a6b..3b95fbb 100644
--- a/ksrc/nucleus/sched.c
+++ b/ksrc/nucleus/sched.c
@@ -395,6 +395,7 @@ int xnsched_set_policy(struct xnthread *thread,
 	thread->sched_class = sched_class;
 	thread->base_class = sched_class;
 	xnsched_setparam(thread, p);
+	thread->bprio = thread->cprio;

 	if (xnthread_test_state(thread, XNREADY))
 		xnsched_enqueue(thread);

> Thanks,
> Jan
> 


-- 
Philippe.

Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> unfortunately I'm forced to switch to other bugs, but I found out a bit
>> more about the issue that pthread_getschedparam doesn't return the
>> correct policy&prio under trunk - at least when called from threads
>> created via pthread_create as SCHED_FIFO:
>>
>> Such threads start with SCHED_OTHER, but then the propagation via
>> do_setsched_event and finally xnsched_set_policy only seems to affect
>> thread.cprio, not bprio. Will see if I can continue debugging this
>> later, but maybe /someone/ already knows what goes wrong...
>>
> 
> With the new scheduler infrastructure, ->bprio tends to be used solely as a
> priority backup area when dealing with PIP; but at the same time, some skins
> still consider it as an always up-to-date location where to find the nominal
> priority of a thread, so this hunk should help in keeping things compatible with
> 2.4.x:

Yes, the posix spec specifically ask that the priority as set by
pthread_setschedparam is returned, and not the boosted priority in case
of PIP.

-- 
                                                 Gilles.