Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-19 Thread Philippe Gerum 
On 04/19/2018 11:24 AM, Jan Kiszka wrote:
> On 2018-04-19 11:17, Philippe Gerum wrote:
>> On 04/17/2018 09:30 AM, Jan Kiszka wrote:
>>> On 2018-04-17 09:22, Philippe Gerum wrote:
 On 04/13/2018 07:51 PM, Jan Kiszka wrote:
> None of the callers that run into the locks have RT requirements.
>
> Signed-off-by: Jan Kiszka 
> ---
>
> As noted before, I think we should even be fine with STD locks, but that
> may require more changes.
>
>  lib/copperplate/registry.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
> index daefa6c97..1bf0ebfea 100644
> --- a/lib/copperplate/registry.c
> +++ b/lib/copperplate/registry.c
> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>  
>   pthread_mutexattr_init(&mattr);
>   pthread_mutexattr_settype(&mattr, mutex_type_attribute);
> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>   pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>   ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>   pthread_mutexattr_destroy(&mattr);
> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char 
> *mountpt, int flags)
>  
>   pthread_mutexattr_init(&mattr);
>   pthread_mutexattr_settype(&mattr, mutex_type_attribute);
> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>   pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>   ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>   pthread_mutexattr_destroy(&mattr);
>

 This one raises an interesting issue: since commit #8e606e681,
 registry_{add, destroy}_file() use plain malloc(), therefore are subject
 to mode switches, dropping the real-time guarantee from object
 creation/deletion routines such as rt_*_{create, delete}() calls from
 the Alchemy API.

 Previously to such change, some of these routines did not provide such
 guarantee anyway, e.g. rt_task_create(), but others did like
 rt_mutex_create(), rt_cond_create().

 I'm now questioning those specific changes in registry_{add,
 destroy}_file(), because they might break applications assuming that rt
 mode is not lost when calling them, which is still true if the registry
 is disabled, leading to a fairly confusing inconsistency.

 Merging your patch would enforce this change in behavior even more,
 carving in stone that all object creation and deletion routines which
 interface with the registry won't be rt-capable anymore.
>>>
>>> Sure, we need to sort out the rt_*_create topic prior to being able to
>>> decide about this one.
>>>

 Would that be generally acceptable?
>>>
>>> I would not expect a lot use cases to be affected by that. The bare
>>> minimum would be documenting this in the 2->3 migration guide.
>>>
>>> OTOH, given that this is the stable series, such a change (8e606e681)
>>> may better wait for 3.1.
>>>
>>
>> This change should be reverted. The more I think of it, the more I see
>> no reason to restrict object creation/deletion to secondary mode if the
>> actual implementation does not require this.
>>
> 
> Over the time, we consistently moved more and more parts away from
> RT-capable object creation/destruction, though.
> 

Driver-wise sure, not in the non-POSIX APIs where traditional RTOS don't
usually enforce such restriction, and copperplate is there to support
those APIs specifically. If this is about preventing regressions, then
introducing this restriction in existing apps - which assumed no latency
issue would exist with creating (lightweight) objects on the fly - could
be a problem. That is what should wait for 3.1, with proper
documentation of the change in behavior.

Only registry_add_file() and registry_destroy_file() would need to be
switched to xn* calls in 3.0.x to fix the original issue, and prevent
regression. The rest lives on top of the fuse fs server thread and is
fine with plain malloc.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-19 Thread Jan Kiszka 
On 2018-04-19 11:17, Philippe Gerum wrote:
> On 04/17/2018 09:30 AM, Jan Kiszka wrote:
>> On 2018-04-17 09:22, Philippe Gerum wrote:
>>> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
 None of the callers that run into the locks have RT requirements.

 Signed-off-by: Jan Kiszka 
 ---

 As noted before, I think we should even be fine with STD locks, but that
 may require more changes.

  lib/copperplate/registry.c | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
 index daefa6c97..1bf0ebfea 100644
 --- a/lib/copperplate/registry.c
 +++ b/lib/copperplate/registry.c
 @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
  
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
 -  pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);
 @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char 
 *mountpt, int flags)
  
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
 -  pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);

>>>
>>> This one raises an interesting issue: since commit #8e606e681,
>>> registry_{add, destroy}_file() use plain malloc(), therefore are subject
>>> to mode switches, dropping the real-time guarantee from object
>>> creation/deletion routines such as rt_*_{create, delete}() calls from
>>> the Alchemy API.
>>>
>>> Previously to such change, some of these routines did not provide such
>>> guarantee anyway, e.g. rt_task_create(), but others did like
>>> rt_mutex_create(), rt_cond_create().
>>>
>>> I'm now questioning those specific changes in registry_{add,
>>> destroy}_file(), because they might break applications assuming that rt
>>> mode is not lost when calling them, which is still true if the registry
>>> is disabled, leading to a fairly confusing inconsistency.
>>>
>>> Merging your patch would enforce this change in behavior even more,
>>> carving in stone that all object creation and deletion routines which
>>> interface with the registry won't be rt-capable anymore.
>>
>> Sure, we need to sort out the rt_*_create topic prior to being able to
>> decide about this one.
>>
>>>
>>> Would that be generally acceptable?
>>
>> I would not expect a lot use cases to be affected by that. The bare
>> minimum would be documenting this in the 2->3 migration guide.
>>
>> OTOH, given that this is the stable series, such a change (8e606e681)
>> may better wait for 3.1.
>>
> 
> This change should be reverted. The more I think of it, the more I see
> no reason to restrict object creation/deletion to secondary mode if the
> actual implementation does not require this.
> 

Over the time, we consistently moved more and more parts away from
RT-capable object creation/destruction, though.

Jan

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-19 Thread Philippe Gerum 
On 04/19/2018 11:17 AM, Philippe Gerum wrote:
> On 04/17/2018 09:30 AM, Jan Kiszka wrote:
>> On 2018-04-17 09:22, Philippe Gerum wrote:
>>> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
 None of the callers that run into the locks have RT requirements.

 Signed-off-by: Jan Kiszka 
 ---

 As noted before, I think we should even be fine with STD locks, but that
 may require more changes.

  lib/copperplate/registry.c | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
 index daefa6c97..1bf0ebfea 100644
 --- a/lib/copperplate/registry.c
 +++ b/lib/copperplate/registry.c
 @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
  
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
 -  pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);
 @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char 
 *mountpt, int flags)
  
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
 -  pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);

>>>
>>> This one raises an interesting issue: since commit #8e606e681,
>>> registry_{add, destroy}_file() use plain malloc(), therefore are subject
>>> to mode switches, dropping the real-time guarantee from object
>>> creation/deletion routines such as rt_*_{create, delete}() calls from
>>> the Alchemy API.
>>>
>>> Previously to such change, some of these routines did not provide such
>>> guarantee anyway, e.g. rt_task_create(), but others did like
>>> rt_mutex_create(), rt_cond_create().
>>>
>>> I'm now questioning those specific changes in registry_{add,
>>> destroy}_file(), because they might break applications assuming that rt
>>> mode is not lost when calling them, which is still true if the registry
>>> is disabled, leading to a fairly confusing inconsistency.
>>>
>>> Merging your patch would enforce this change in behavior even more,
>>> carving in stone that all object creation and deletion routines which
>>> interface with the registry won't be rt-capable anymore.
>>
>> Sure, we need to sort out the rt_*_create topic prior to being able to
>> decide about this one.
>>
>>>
>>> Would that be generally acceptable?
>>
>> I would not expect a lot use cases to be affected by that. The bare
>> minimum would be documenting this in the 2->3 migration guide.
>>
>> OTOH, given that this is the stable series, such a change (8e606e681)
>> may better wait for 3.1.
>>
> 
> This change should be reverted. The more I think of it, the more I see
> no reason to restrict object creation/deletion to secondary mode if the
> actual implementation does not require this.
> 

In fact, pv* calls there should simply move to xn* counterparts, fixing
the issue without any change in behavior.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-19 Thread Philippe Gerum 
On 04/17/2018 09:30 AM, Jan Kiszka wrote:
> On 2018-04-17 09:22, Philippe Gerum wrote:
>> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
>>> None of the callers that run into the locks have RT requirements.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> ---
>>>
>>> As noted before, I think we should even be fine with STD locks, but that
>>> may require more changes.
>>>
>>>  lib/copperplate/registry.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
>>> index daefa6c97..1bf0ebfea 100644
>>> --- a/lib/copperplate/registry.c
>>> +++ b/lib/copperplate/registry.c
>>> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>>>  
>>> pthread_mutexattr_init(&mattr);
>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>> -   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>> ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>>> pthread_mutexattr_destroy(&mattr);
>>> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char 
>>> *mountpt, int flags)
>>>  
>>> pthread_mutexattr_init(&mattr);
>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>> -   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>> ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>>> pthread_mutexattr_destroy(&mattr);
>>>
>>
>> This one raises an interesting issue: since commit #8e606e681,
>> registry_{add, destroy}_file() use plain malloc(), therefore are subject
>> to mode switches, dropping the real-time guarantee from object
>> creation/deletion routines such as rt_*_{create, delete}() calls from
>> the Alchemy API.
>>
>> Previously to such change, some of these routines did not provide such
>> guarantee anyway, e.g. rt_task_create(), but others did like
>> rt_mutex_create(), rt_cond_create().
>>
>> I'm now questioning those specific changes in registry_{add,
>> destroy}_file(), because they might break applications assuming that rt
>> mode is not lost when calling them, which is still true if the registry
>> is disabled, leading to a fairly confusing inconsistency.
>>
>> Merging your patch would enforce this change in behavior even more,
>> carving in stone that all object creation and deletion routines which
>> interface with the registry won't be rt-capable anymore.
> 
> Sure, we need to sort out the rt_*_create topic prior to being able to
> decide about this one.
> 
>>
>> Would that be generally acceptable?
> 
> I would not expect a lot use cases to be affected by that. The bare
> minimum would be documenting this in the 2->3 migration guide.
> 
> OTOH, given that this is the stable series, such a change (8e606e681)
> may better wait for 3.1.
> 

This change should be reverted. The more I think of it, the more I see
no reason to restrict object creation/deletion to secondary mode if the
actual implementation does not require this.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-17 Thread Philippe Gerum 
On 04/17/2018 09:30 AM, Jan Kiszka wrote:
> On 2018-04-17 09:22, Philippe Gerum wrote:
>> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
>>> None of the callers that run into the locks have RT requirements.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> ---
>>>
>>> As noted before, I think we should even be fine with STD locks, but that
>>> may require more changes.
>>>
>>>  lib/copperplate/registry.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
>>> index daefa6c97..1bf0ebfea 100644
>>> --- a/lib/copperplate/registry.c
>>> +++ b/lib/copperplate/registry.c
>>> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>>>  
>>> pthread_mutexattr_init(&mattr);
>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>> -   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>> ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>>> pthread_mutexattr_destroy(&mattr);
>>> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char 
>>> *mountpt, int flags)
>>>  
>>> pthread_mutexattr_init(&mattr);
>>> pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>>> -   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>> pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>> ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>>> pthread_mutexattr_destroy(&mattr);
>>>
>>
>> This one raises an interesting issue: since commit #8e606e681,
>> registry_{add, destroy}_file() use plain malloc(), therefore are subject
>> to mode switches, dropping the real-time guarantee from object
>> creation/deletion routines such as rt_*_{create, delete}() calls from
>> the Alchemy API.
>>
>> Previously to such change, some of these routines did not provide such
>> guarantee anyway, e.g. rt_task_create(), but others did like
>> rt_mutex_create(), rt_cond_create().
>>
>> I'm now questioning those specific changes in registry_{add,
>> destroy}_file(), because they might break applications assuming that rt
>> mode is not lost when calling them, which is still true if the registry
>> is disabled, leading to a fairly confusing inconsistency.
>>
>> Merging your patch would enforce this change in behavior even more,
>> carving in stone that all object creation and deletion routines which
>> interface with the registry won't be rt-capable anymore.
> 
> Sure, we need to sort out the rt_*_create topic prior to being able to
> decide about this one.
> 
>>
>> Would that be generally acceptable?
> 
> I would not expect a lot use cases to be affected by that. The bare
> minimum would be documenting this in the 2->3 migration guide.
> 
> OTOH, given that this is the stable series, such a change (8e606e681)
> may better wait for 3.1.
> 
>>
>> PS: btw, the memory allocation mess is much worse than I suspected, and
>> it is globally bad: this is not only a matter of properly sizing the
>> private memory heap, but a general performance issues with all
>> allocators, on different aspects and usage patterns. I'll follow up on
>> this later this week with details.
> 
> Is that related to 8e606e681 or does it predate it / is orthogonal to it?
> 

Orthogonal, most allocators we use have serious performance flaws on
release (core xnheap, pshared), the only one which does not has a bad
fragmentation issue (tlsf).

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-17 Thread Jan Kiszka 
On 2018-04-17 09:22, Philippe Gerum wrote:
> On 04/13/2018 07:51 PM, Jan Kiszka wrote:
>> None of the callers that run into the locks have RT requirements.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>
>> As noted before, I think we should even be fine with STD locks, but that
>> may require more changes.
>>
>>  lib/copperplate/registry.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
>> index daefa6c97..1bf0ebfea 100644
>> --- a/lib/copperplate/registry.c
>> +++ b/lib/copperplate/registry.c
>> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>>  
>>  pthread_mutexattr_init(&mattr);
>>  pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>> -pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>  pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>  ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>>  pthread_mutexattr_destroy(&mattr);
>> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char *mountpt, 
>> int flags)
>>  
>>  pthread_mutexattr_init(&mattr);
>>  pthread_mutexattr_settype(&mattr, mutex_type_attribute);
>> -pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>>  pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>>  ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>>  pthread_mutexattr_destroy(&mattr);
>>
> 
> This one raises an interesting issue: since commit #8e606e681,
> registry_{add, destroy}_file() use plain malloc(), therefore are subject
> to mode switches, dropping the real-time guarantee from object
> creation/deletion routines such as rt_*_{create, delete}() calls from
> the Alchemy API.
> 
> Previously to such change, some of these routines did not provide such
> guarantee anyway, e.g. rt_task_create(), but others did like
> rt_mutex_create(), rt_cond_create().
> 
> I'm now questioning those specific changes in registry_{add,
> destroy}_file(), because they might break applications assuming that rt
> mode is not lost when calling them, which is still true if the registry
> is disabled, leading to a fairly confusing inconsistency.
> 
> Merging your patch would enforce this change in behavior even more,
> carving in stone that all object creation and deletion routines which
> interface with the registry won't be rt-capable anymore.

Sure, we need to sort out the rt_*_create topic prior to being able to
decide about this one.

> 
> Would that be generally acceptable?

I would not expect a lot use cases to be affected by that. The bare
minimum would be documenting this in the 2->3 migration guide.

OTOH, given that this is the stable series, such a change (8e606e681)
may better wait for 3.1.

> 
> PS: btw, the memory allocation mess is much worse than I suspected, and
> it is globally bad: this is not only a matter of properly sizing the
> private memory heap, but a general performance issues with all
> allocators, on different aspects and usage patterns. I'll follow up on
> this later this week with details.

Is that related to 8e606e681 or does it predate it / is orthogonal to it?

Jan
-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-17 Thread Philippe Gerum 
On 04/13/2018 07:51 PM, Jan Kiszka wrote:
> None of the callers that run into the locks have RT requirements.
> 
> Signed-off-by: Jan Kiszka 
> ---
> 
> As noted before, I think we should even be fine with STD locks, but that
> may require more changes.
> 
>  lib/copperplate/registry.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
> index daefa6c97..1bf0ebfea 100644
> --- a/lib/copperplate/registry.c
> +++ b/lib/copperplate/registry.c
> @@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
>  
>   pthread_mutexattr_init(&mattr);
>   pthread_mutexattr_settype(&mattr, mutex_type_attribute);
> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>   pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>   ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
>   pthread_mutexattr_destroy(&mattr);
> @@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char *mountpt, 
> int flags)
>  
>   pthread_mutexattr_init(&mattr);
>   pthread_mutexattr_settype(&mattr, mutex_type_attribute);
> - pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
>   pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
>   ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
>   pthread_mutexattr_destroy(&mattr);
> 

This one raises an interesting issue: since commit #8e606e681,
registry_{add, destroy}_file() use plain malloc(), therefore are subject
to mode switches, dropping the real-time guarantee from object
creation/deletion routines such as rt_*_{create, delete}() calls from
the Alchemy API.

Previously to such change, some of these routines did not provide such
guarantee anyway, e.g. rt_task_create(), but others did like
rt_mutex_create(), rt_cond_create().

I'm now questioning those specific changes in registry_{add,
destroy}_file(), because they might break applications assuming that rt
mode is not lost when calling them, which is still true if the registry
is disabled, leading to a fairly confusing inconsistency.

Merging your patch would enforce this change in behavior even more,
carving in stone that all object creation and deletion routines which
interface with the registry won't be rt-capable anymore.

Would that be generally acceptable?

PS: btw, the memory allocation mess is much worse than I suspected, and
it is globally bad: this is not only a matter of properly sizing the
private memory heap, but a general performance issues with all
allocators, on different aspects and usage patterns. I'll follow up on
this later this week with details.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] [PATCH] copperplate: Drop PI from registry locks

2018-04-13 Thread Jan Kiszka 
None of the callers that run into the locks have RT requirements.

Signed-off-by: Jan Kiszka 
---

As noted before, I think we should even be fine with STD locks, but that
may require more changes.

 lib/copperplate/registry.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/copperplate/registry.c b/lib/copperplate/registry.c
index daefa6c97..1bf0ebfea 100644
--- a/lib/copperplate/registry.c
+++ b/lib/copperplate/registry.c
@@ -175,7 +175,6 @@ int registry_init_file(struct fsobj *fsobj,
 
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
-   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&fsobj->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);
@@ -758,7 +757,6 @@ int __registry_pkg_init(const char *arg0, char *mountpt, 
int flags)
 
pthread_mutexattr_init(&mattr);
pthread_mutexattr_settype(&mattr, mutex_type_attribute);
-   pthread_mutexattr_setprotocol(&mattr, PTHREAD_PRIO_INHERIT);
pthread_mutexattr_setpshared(&mattr, PTHREAD_PROCESS_PRIVATE);
ret = __bt(-__RT(pthread_mutex_init(&p->lock, &mattr)));
pthread_mutexattr_destroy(&mattr);

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai