Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] trunk: xnsched_set_policy seems to set only cprio
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
