Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Gilles Chanteperdrix wrote:
> Author: gch
> Date: Sat Oct  4 23:11:09 2008
> New Revision: 4210
> 
> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
> Log:
> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.

Well, I dropped this idea after realizing that it will kick us out of
primary mode in all cases. This change is an improvement (/wrt Linux
scheduling accuracy) for borderline threads, but it will cause
regressions for primary-only threads. I have no idea right now how to
make both happy, at least without explicit pthread_setschedparam
invocations by the user application.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Author: gch
>> Date: Sat Oct  4 23:11:09 2008
>> New Revision: 4210
>>
>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>> Log:
>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
> 
> Well, I dropped this idea after realizing that it will kick us out of
> primary mode in all cases. This change is an improvement (/wrt Linux
> scheduling accuracy) for borderline threads, but it will cause
> regressions for primary-only threads. I have no idea right now how to
> make both happy, at least without explicit pthread_setschedparam
> invocations by the user application.

Well, we discussed this on the xenomai mailing list, you did not answer,
so we assumed you agreed.

-- 
					    Gilles.

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Author: gch
>>> Date: Sat Oct  4 23:11:09 2008
>>> New Revision: 4210
>>>
>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>> Log:
>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>> Well, I dropped this idea after realizing that it will kick us out of
>> primary mode in all cases. This change is an improvement (/wrt Linux
>> scheduling accuracy) for borderline threads, but it will cause
>> regressions for primary-only threads. I have no idea right now how to
>> make both happy, at least without explicit pthread_setschedparam
>> invocations by the user application.
> 
> Well, we discussed this on the xenomai mailing list, you did not answer,
> so we assumed you agreed.

I meant xenomai-core.
https://mail.gna.org/public/xenomai-core/2008-10/msg00005.html

-- 
					    Gilles.

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Author: gch
>>> Date: Sat Oct  4 23:11:09 2008
>>> New Revision: 4210
>>>
>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>> Log:
>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>> Well, I dropped this idea after realizing that it will kick us out of
>> primary mode in all cases. This change is an improvement (/wrt Linux
>> scheduling accuracy) for borderline threads, but it will cause
>> regressions for primary-only threads. I have no idea right now how to
>> make both happy, at least without explicit pthread_setschedparam
>> invocations by the user application.
> 
> Well, we discussed this on the xenomai mailing list, you did not answer,
> so we assumed you agreed.

I do not find any hint in that thread that we agreed on changing the
implementation. Rather I took back my suggestion to do it like #4210.
And you proposed to install some signal for syncing glibc /wrt
priorities. When changing something, then I would say explore this path
first.

Turning rt_task_set_priority into secondary-mode service is a critical
change, and only the last resort if we consider its current
implementation as totally broken - I wouldn't say it is like that. It's
partially and, unfortunately, silently broken, ie. lacking documentation
about its limitations. But its perfectly OK for primary-only users.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Author: gch
>>>> Date: Sat Oct  4 23:11:09 2008
>>>> New Revision: 4210
>>>>
>>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>> Log:
>>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>>> Well, I dropped this idea after realizing that it will kick us out of
>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>> scheduling accuracy) for borderline threads, but it will cause
>>> regressions for primary-only threads. I have no idea right now how to
>>> make both happy, at least without explicit pthread_setschedparam
>>> invocations by the user application.
>> Well, we discussed this on the xenomai mailing list, you did not answer,
>> so we assumed you agreed.
> 
> I do not find any hint in that thread that we agreed on changing the
> implementation. Rather I took back my suggestion to do it like #4210.
> And you proposed to install some signal for syncing glibc /wrt
> priorities. When changing something, then I would say explore this path
> first.

We are used to hear you when you do disagree... So, since you did not
answer Philippe mail who said "it is certainly debatable", we assumed
you agreed. But we certainly were wrong.

> 
> Turning rt_task_set_priority into secondary-mode service is a critical
> change, and only the last resort if we consider its current
> implementation as totally broken - I wouldn't say it is like that. It's
> partially and, unfortunately, silently broken, ie. lacking documentation
> about its limitations. But its perfectly OK for primary-only users.

No, an important invariant of Xenomai is that the priority scales are
synchronized between Xenomai and Linux. So, if Linux does not see the
same priority as Xenomai, the implementation is broken. Imagine for
instance that your primary-only thread posts an NPTL semaphore, knowing
that a switch will not occur so that it will not leave primary mode. If
the glibc does not see the correct priority, then a mode switch may
occur whereas it should not. This is a bit far-fetched, but who knows
what else may happen if the priorities are not synchronized. We
absolutely want the priorities to be synchronized.


-- 
					    Gilles.

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Author: gch
>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>> New Revision: 4210
>>>>>
>>>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>>> Log:
>>>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>> scheduling accuracy) for borderline threads, but it will cause
>>>> regressions for primary-only threads. I have no idea right now how to
>>>> make both happy, at least without explicit pthread_setschedparam
>>>> invocations by the user application.
>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>> so we assumed you agreed.
>> I do not find any hint in that thread that we agreed on changing the
>> implementation. Rather I took back my suggestion to do it like #4210.
>> And you proposed to install some signal for syncing glibc /wrt
>> priorities. When changing something, then I would say explore this path
>> first.
> 
> We are used to hear you when you do disagree... So, since you did not
> answer Philippe mail who said "it is certainly debatable", we assumed
> you agreed. But we certainly were wrong.
> 
>> Turning rt_task_set_priority into secondary-mode service is a critical
>> change, and only the last resort if we consider its current
>> implementation as totally broken - I wouldn't say it is like that. It's
>> partially and, unfortunately, silently broken, ie. lacking documentation
>> about its limitations. But its perfectly OK for primary-only users.
> 
> No, an important invariant of Xenomai is that the priority scales are
> synchronized between Xenomai and Linux. So, if Linux does not see the
> same priority as Xenomai, the implementation is broken. Imagine for
> instance that your primary-only thread posts an NPTL semaphore, knowing
> that a switch will not occur so that it will not leave primary mode. If
> the glibc does not see the correct priority, then a mode switch may
> occur whereas it should not. This is a bit far-fetched, but who knows
> what else may happen if the priorities are not synchronized. We
> absolutely want the priorities to be synchronized.

Ok. I am looking at the SIGWINCH change.

-- 
					    Gilles.

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3300 bytes --]

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Author: gch
>>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>>> New Revision: 4210
>>>>>>
>>>>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>>>> Log:
>>>>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>>> scheduling accuracy) for borderline threads, but it will cause
>>>>> regressions for primary-only threads. I have no idea right now how to
>>>>> make both happy, at least without explicit pthread_setschedparam
>>>>> invocations by the user application.
>>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>>> so we assumed you agreed.
>>> I do not find any hint in that thread that we agreed on changing the
>>> implementation. Rather I took back my suggestion to do it like #4210.
>>> And you proposed to install some signal for syncing glibc /wrt
>>> priorities. When changing something, then I would say explore this path
>>> first.
>> We are used to hear you when you do disagree... So, since you did not
>> answer Philippe mail who said "it is certainly debatable", we assumed
>> you agreed. But we certainly were wrong.

I may have misunderstood that this early statement in the discussion was
still valid after we dug deeper into the topic.

>>
>>> Turning rt_task_set_priority into secondary-mode service is a critical
>>> change, and only the last resort if we consider its current
>>> implementation as totally broken - I wouldn't say it is like that. It's
>>> partially and, unfortunately, silently broken, ie. lacking documentation
>>> about its limitations. But its perfectly OK for primary-only users.
>> No, an important invariant of Xenomai is that the priority scales are
>> synchronized between Xenomai and Linux. So, if Linux does not see the
>> same priority as Xenomai, the implementation is broken. Imagine for
>> instance that your primary-only thread posts an NPTL semaphore, knowing
>> that a switch will not occur so that it will not leave primary mode. If
>> the glibc does not see the correct priority, then a mode switch may
>> occur whereas it should not. This is a bit far-fetched, but who knows
>> what else may happen if the priorities are not synchronized. We
>> absolutely want the priorities to be synchronized.

I understand the deep desire to keep the priorities in sync for those
threads that go to secondary mode (or at least accept occasional switches).

But no one will (OK: should) seriously build a primary-only design based
on assumptions about the glibc locking and syscall behavior. Practice
teaches that this is doomed to break - at latest on next glibc update
(or what other standard third-party lib). Primary-only means only safe
Xenomai services or well-audited library calls. So turning some Xenomai
service into an unsafe one remains a critical step, even if it fixes
other use cases.

> 
> Ok. I am looking at the SIGWINCH change.
> 

Great, TiA.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Author: gch
>>>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>>>> New Revision: 4210
>>>>>>>
>>>>>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>>>>> Log:
>>>>>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>>>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>>>> scheduling accuracy) for borderline threads, but it will cause
>>>>>> regressions for primary-only threads. I have no idea right now how to
>>>>>> make both happy, at least without explicit pthread_setschedparam
>>>>>> invocations by the user application.
>>>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>>>> so we assumed you agreed.
>>>> I do not find any hint in that thread that we agreed on changing the
>>>> implementation. Rather I took back my suggestion to do it like #4210.
>>>> And you proposed to install some signal for syncing glibc /wrt
>>>> priorities. When changing something, then I would say explore this path
>>>> first.
>>> We are used to hear you when you do disagree... So, since you did not
>>> answer Philippe mail who said "it is certainly debatable", we assumed
>>> you agreed. But we certainly were wrong.
> 
> I may have misunderstood that this early statement in the discussion was
> still valid after we dug deeper into the topic.
> 
>>>> Turning rt_task_set_priority into secondary-mode service is a critical
>>>> change, and only the last resort if we consider its current
>>>> implementation as totally broken - I wouldn't say it is like that. It's
>>>> partially and, unfortunately, silently broken, ie. lacking documentation
>>>> about its limitations. But its perfectly OK for primary-only users.
>>> No, an important invariant of Xenomai is that the priority scales are
>>> synchronized between Xenomai and Linux. So, if Linux does not see the
>>> same priority as Xenomai, the implementation is broken. Imagine for
>>> instance that your primary-only thread posts an NPTL semaphore, knowing
>>> that a switch will not occur so that it will not leave primary mode. If
>>> the glibc does not see the correct priority, then a mode switch may
>>> occur whereas it should not. This is a bit far-fetched, but who knows
>>> what else may happen if the priorities are not synchronized. We
>>> absolutely want the priorities to be synchronized.
> 
> I understand the deep desire to keep the priorities in sync for those
> threads that go to secondary mode (or at least accept occasional switches).
> 
> But no one will (OK: should) seriously build a primary-only design based
> on assumptions about the glibc locking and syscall behavior. Practice
> teaches that this is doomed to break - at latest on next glibc update
> (or what other standard third-party lib). Primary-only means only safe
> Xenomai services or well-audited library calls. So turning some Xenomai
> service into an unsafe one remains a critical step, even if it fixes
> other use cases.
> 
>> Ok. I am looking at the SIGWINCH change.
>>
> 
> Great, TiA.

I am not optimistic. I see no way for now to change this without
breaking the ABI.

-- 
					    Gilles.

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Author: gch
>>>>>>>> Date: Sat Oct  4 23:11:09 2008
>>>>>>>> New Revision: 4210
>>>>>>>>
>>>>>>>> URL: http://svn.gna.org/viewcvs/xenomai?rev=4210&view=rev
>>>>>>>> Log:
>>>>>>>> Call __real_pthread_setschedparam in order to inform the libc of the scheduling parameters change.
>>>>>>> Well, I dropped this idea after realizing that it will kick us out of
>>>>>>> primary mode in all cases. This change is an improvement (/wrt Linux
>>>>>>> scheduling accuracy) for borderline threads, but it will cause
>>>>>>> regressions for primary-only threads. I have no idea right now how to
>>>>>>> make both happy, at least without explicit pthread_setschedparam
>>>>>>> invocations by the user application.
>>>>>> Well, we discussed this on the xenomai mailing list, you did not answer,
>>>>>> so we assumed you agreed.
>>>>> I do not find any hint in that thread that we agreed on changing the
>>>>> implementation. Rather I took back my suggestion to do it like #4210.
>>>>> And you proposed to install some signal for syncing glibc /wrt
>>>>> priorities. When changing something, then I would say explore this path
>>>>> first.
>>>> We are used to hear you when you do disagree... So, since you did not
>>>> answer Philippe mail who said "it is certainly debatable", we assumed
>>>> you agreed. But we certainly were wrong.
>> I may have misunderstood that this early statement in the discussion was
>> still valid after we dug deeper into the topic.
>>
>>>>> Turning rt_task_set_priority into secondary-mode service is a critical
>>>>> change, and only the last resort if we consider its current
>>>>> implementation as totally broken - I wouldn't say it is like that. It's
>>>>> partially and, unfortunately, silently broken, ie. lacking documentation
>>>>> about its limitations. But its perfectly OK for primary-only users.
>>>> No, an important invariant of Xenomai is that the priority scales are
>>>> synchronized between Xenomai and Linux. So, if Linux does not see the
>>>> same priority as Xenomai, the implementation is broken. Imagine for
>>>> instance that your primary-only thread posts an NPTL semaphore, knowing
>>>> that a switch will not occur so that it will not leave primary mode. If
>>>> the glibc does not see the correct priority, then a mode switch may
>>>> occur whereas it should not. This is a bit far-fetched, but who knows
>>>> what else may happen if the priorities are not synchronized. We
>>>> absolutely want the priorities to be synchronized.
>> I understand the deep desire to keep the priorities in sync for those
>> threads that go to secondary mode (or at least accept occasional switches).
>>
>> But no one will (OK: should) seriously build a primary-only design based
>> on assumptions about the glibc locking and syscall behavior. Practice
>> teaches that this is doomed to break - at latest on next glibc update
>> (or what other standard third-party lib). Primary-only means only safe
>> Xenomai services or well-audited library calls. So turning some Xenomai
>> service into an unsafe one remains a critical step, even if it fixes
>> other use cases.
>>
>>> Ok. I am looking at the SIGWINCH change.
>>>
>> Great, TiA.
> 
> I am not optimistic. I see no way for now to change this without
> breaking the ABI.

Well, both the current change as well as a potential signal-based prio
update would be 2.5 material IMHO. So ABI breakage is not an issue. I
wouldn't touch 2.4 unless there is a transparent fix feasible (which I
doubt as well).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [Xenomai-commits] r4210 - in /trunk: ChangeLog src/skins/native/task.c

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Well, both the current change as well as a potential signal-based prio
> update would be 2.5 material IMHO. So ABI breakage is not an issue. I
> wouldn't touch 2.4 unless there is a transparent fix feasible (which I
> doubt as well).

The current change does not break the ABIT, it just breaks already
broken applications...

-- 
					    Gilles.