[Xenomai-core] rt_task_set_priority vs. Linux priority

[Xenomai-core] rt_task_set_priority vs. Linux priority

[Jan Kiszka]

Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler parameters and calling that service would be
better, no?

Jan

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

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Quick question $customer stumbled over: Shouldn't the user space part of
> rt_task_set_priority also (or rather?) adjust the Linux priority of the
> caller? My impression is yes. Actually, translating the native priority
> to sched_setscheduler parameters and calling that service would be
> better, no?

I believe Philippe already fixed that in trunk.

-- 
                                                 Gilles.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Quick question $customer stumbled over: Shouldn't the user space part of
>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>> caller? My impression is yes. Actually, translating the native priority
>> to sched_setscheduler parameters and calling that service would be
>> better, no?
> 
> I believe Philippe already fixed that in trunk.

Actually, this does not seem to be fixed in trunk. However, you should
use pthread_setschedparam instead of sched_setscheduler: ISTR that
sched_setscheduler sets the priorites of all threads.

-- 
                                                 Gilles.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Quick question $customer stumbled over: Shouldn't the user space part of
>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>> caller? My impression is yes. Actually, translating the native priority
>> to sched_setscheduler parameters and calling that service would be
>> better, no?
> 
> I believe Philippe already fixed that in trunk.
> 

Hmmm... but we are on trunk, just a few weeks old...

The scenario, as far as I understood it, is that rt_task_set_priority is
called from primary context. But the propagation in
xnpod_renice_thread_inner targets relaxed contexts only. Probably that's
the core of the issue. We need to propagate the modification when
migrating next time. Maybe some flag "update Linux prio" so that we only
go that way when actually required.

BTW, strike my idea of using plain sched_setscheduler - would kick us
out of primary mode unconditionally.

Jan

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

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Quick question $customer stumbled over: Shouldn't the user space part of
>>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>>> caller? My impression is yes. Actually, translating the native priority
>>> to sched_setscheduler parameters and calling that service would be
>>> better, no?
>> I believe Philippe already fixed that in trunk.
>>
> 
> Hmmm... but we are on trunk, just a few weeks old...
> 
> The scenario, as far as I understood it, is that rt_task_set_priority is
> called from primary context. But the propagation in
> xnpod_renice_thread_inner targets relaxed contexts only. Probably that's
> the core of the issue. We need to propagate the modification when
> migrating next time. Maybe some flag "update Linux prio" so that we only
> go that way when actually required.
> 
> BTW, strike my idea of using plain sched_setscheduler - would kick us
> out of primary mode unconditionally.

No, you should use pthread_setschedparam, and yes, it will kick us out
of primary mode, but we decided that it was preferable to complicated
alternatives: pthread_setschedparam is the only way for libc to be
informed of the priority change. Libc has its only idea of what the
priority of a thread is, so, we can not change the priority only in the
kernel.

-- 
                                                 Gilles.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Quick question $customer stumbled over: Shouldn't the user space part of
>>>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>>>> caller? My impression is yes. Actually, translating the native priority
>>>> to sched_setscheduler parameters and calling that service would be
>>>> better, no?
>>> I believe Philippe already fixed that in trunk.
>>>
>> Hmmm... but we are on trunk, just a few weeks old...
>>
>> The scenario, as far as I understood it, is that rt_task_set_priority is
>> called from primary context. But the propagation in
>> xnpod_renice_thread_inner targets relaxed contexts only. Probably that's
>> the core of the issue. We need to propagate the modification when
>> migrating next time. Maybe some flag "update Linux prio" so that we only
>> go that way when actually required.
>>
>> BTW, strike my idea of using plain sched_setscheduler - would kick us
>> out of primary mode unconditionally.
> 
> No, you should use pthread_setschedparam, and yes, it will kick us out
> of primary mode, but we decided that it was preferable to complicated
> alternatives: pthread_setschedparam is the only way for libc to be
> informed of the priority change. Libc has its only idea of what the
> priority of a thread is, so, we can not change the priority only in the
> kernel.

So we should warn the user (in the doc) that rt_task_set_priority will
leave an inconsistent priority distribution between Linux and Xenomai
behind? But what is that propagation path in xnpod_renice_thread_inner
good for then?

Jan

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

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Philippe Gerum]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Quick question $customer stumbled over: Shouldn't the user space part of
>>>>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>>>>> caller? My impression is yes. Actually, translating the native priority
>>>>> to sched_setscheduler parameters and calling that service would be
>>>>> better, no?
>>>> I believe Philippe already fixed that in trunk.
>>>>
>>> Hmmm... but we are on trunk, just a few weeks old...
>>>
>>> The scenario, as far as I understood it, is that rt_task_set_priority is
>>> called from primary context. But the propagation in
>>> xnpod_renice_thread_inner targets relaxed contexts only. Probably that's
>>> the core of the issue. We need to propagate the modification when
>>> migrating next time. Maybe some flag "update Linux prio" so that we only
>>> go that way when actually required.
>>>
>>> BTW, strike my idea of using plain sched_setscheduler - would kick us
>>> out of primary mode unconditionally.
>> No, you should use pthread_setschedparam, and yes, it will kick us out
>> of primary mode, but we decided that it was preferable to complicated
>> alternatives: pthread_setschedparam is the only way for libc to be
>> informed of the priority change. Libc has its only idea of what the
>> priority of a thread is, so, we can not change the priority only in the
>> kernel.
> 
> So we should warn the user (in the doc) that rt_task_set_priority will
> leave an inconsistent priority distribution between Linux and Xenomai
> behind? But what is that propagation path in xnpod_renice_thread_inner
> good for then?
>

A failed attempt that used to work before the glibc folks decided to cache the
priority level of threads locally. With the NPTL, it's useless and error-prone.

> Jan
> 


-- 
Philippe.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> So we should warn the user (in the doc) that rt_task_set_priority will
>> leave an inconsistent priority distribution between Linux and Xenomai
>> behind? But what is that propagation path in xnpod_renice_thread_inner
>> good for then?
>>
> 
> A failed attempt that used to work before the glibc folks decided to cache the
> priority level of threads locally. With the NPTL, it's useless and error-prone.

I think linuxthreads already did the caching. So, in fact, it probably
never really worked.

But what is funny is that glibc people have (or had) problems with that
caching too: when you passed priorities to pthread_create, whereas the
kernel used the correct priority, the user-space was not aware of this
priority, so pthread_getschedparam did not return the correct priority.
Which is probably the reason why we need to call pthread_setschedparam
in Xenomai libraries thread trampolines.

-- 
                                                 Gilles.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> So we should warn the user (in the doc) that rt_task_set_priority will
>>> leave an inconsistent priority distribution between Linux and Xenomai
>>> behind? But what is that propagation path in xnpod_renice_thread_inner
>>> good for then?
>>>
>> A failed attempt that used to work before the glibc folks decided to cache the
>> priority level of threads locally. With the NPTL, it's useless and error-prone.
> 
> I think linuxthreads already did the caching. So, in fact, it probably
> never really worked.

Great, that should make my answer to Jan even simpler:
Jan, please read: "A failed attempt".

> 
> But what is funny is that glibc people have (or had) problems with that
> caching too: when you passed priorities to pthread_create, whereas the
> kernel used the correct priority, the user-space was not aware of this
> priority, so pthread_getschedparam did not return the correct priority.
> Which is probably the reason why we need to call pthread_setschedparam
> in Xenomai libraries thread trampolines.
> 

Translation: it's a mess.

-- 
Philippe.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Quick question $customer stumbled over: Shouldn't the user space part of
>> rt_task_set_priority also (or rather?) adjust the Linux priority of the
>> caller? My impression is yes. Actually, translating the native priority
>> to sched_setscheduler parameters and calling that service would be
>> better, no?
> 

The nucleus does this for us, but that is not enough due to the glibc caching
priority levels.

> I believe Philippe already fixed that in trunk.
> 

Mostly yes, but properly only for task creation/shadowing requests. There is
still a problem with the glibc caching the priority level with set_priority()
calls, since we only rely on the nucleus, without telling the glibc about the
change. However, this would trigger a secondary mode switch.

AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an application
design issue. For that reason, enduring a mode switch upon
rt_task_set_priority() calls (and friends) would be ok for me. But that's
certainly debatable.

-- 
Philippe.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> AFAIC, I don't see how changing priorities on the fly within a time critical
> section could be considered as good programming practice; this would tend to
> indicate that somebody is playing with priorities to paper over an application
> design issue.

So, you mean PIP papers over application design issues ? Just kidding...


> For that reason, enduring a mode switch upon
> rt_task_set_priority() calls (and friends) would be ok for me. But that's
> certainly debatable.

Actually, we could trigger a signal for pthread_setschedparam to be
called for next switch to secondary mode. We could re-use the signal
already used to trigger a switch to primary mode for suspending a thread
running in secondary mode, finding a way to multiplex the information
passing, for instance, parameters to the siginfo structure.

-- 
                                                 Gilles.

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> AFAIC, I don't see how changing priorities on the fly within a time critical
>> section could be considered as good programming practice; this would tend to
>> indicate that somebody is playing with priorities to paper over an application
>> design issue.
> 
> So, you mean PIP papers over application design issues ? Just kidding...

In this case, we face an operation mode switch of the thread: It use to
due high prio work in primary mode only, now its finished and what to
flush its data to Linux, but without causing troubles to the Linux
schedule due to its SCHED_FIFO level.

Jan

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

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Jan Kiszka]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Philippe Gerum wrote:
>>> AFAIC, I don't see how changing priorities on the fly within a time critical
>>> section could be considered as good programming practice; this would tend to
>>> indicate that somebody is playing with priorities to paper over an application
>>> design issue.
>> So, you mean PIP papers over application design issues ? Just kidding...
> 
> In this case, we face an operation mode switch of the thread: It use to
> due high prio work in primary mode only, now its finished and what to

"It used to do [...] and wants to [...]" - hell...

> flush its data to Linux, but without causing troubles to the Linux
> schedule due to its SCHED_FIFO level.

Jan

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

Re: [Xenomai-core] rt_task_set_priority vs. Linux priority

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> AFAIC, I don't see how changing priorities on the fly within a time critical
>> section could be considered as good programming practice; this would tend to
>> indicate that somebody is playing with priorities to paper over an application
>> design issue.
> 
> So, you mean PIP papers over application design issues ? Just kidding...
>

PIP means, "well, you know what, I don't want to deal with dynamic resource
conflicts in my application, I don't want to bother defining a ceiling priority
for each of those resources, actually, I'm just unable to tell how they might
interact anyway, so please, beautiful and inspired kernel, GET THIS DAMNED THING
RIGHT FOR ME! Oh, and thank you."

But hey, that's fine! Nothing prevents the kernel from doing the smart job, anyway.

> 
>> For that reason, enduring a mode switch upon
>> rt_task_set_priority() calls (and friends) would be ok for me. But that's
>> certainly debatable.
> 
> Actually, we could trigger a signal for pthread_setschedparam to be
> called for next switch to secondary mode. We could re-use the signal
> already used to trigger a switch to primary mode for suspending a thread
> running in secondary mode, finding a way to multiplex the information
> passing, for instance, parameters to the siginfo structure.
> 

Yep, that would work.

-- 
Philippe.