Re: [Xenomai] Performance issue with memory allocators

[Steve Freyder <steve@freyder.net>]

On 6/15/2018 1:26 PM, Philippe Gerum wrote:
> On 06/15/2018 07:23 PM, Steve Freyder wrote:
>> On 6/14/2018 11:52 AM, Philippe Gerum wrote:
>>> On 06/14/2018 06:41 PM, Steve Freyder wrote:
>>>> #2  0x76f418fc in shavl_search_inner (ops=0x76f56630 <size_search_ops>,
>>>> delta=0x76f418fc <add_free_range+216>, n=0x7eca29d4,
>>>>       avl=0x741f38ec) at
>>>> ../../../../xenomai-3/include/boilerplate/avl-inner.h:285
>>>> #3  shavl_search_nearest (ops=0x76f56630 <size_search_ops>, dir=1,
>>>> node=0x7eca29d4, avl=0x741f38ec)
>>>>       at ../../../../xenomai-3/include/boilerplate/avl-inner.h:395
>>>> #4  shavl_search_ge (ops=0x76f56630 <size_search_ops>, node=0x7eca29d4,
>>>> avl=0x741f38ec)
>>> The search operations parameter is last in the original code, but first
>>> in your backtrace. Does this mean that you had conflicts there and fixed
>>> them up manually? Since this is a new code, I'm unsure why you had such
>>> conflicts in the first place.
>>>
>>> Could you check with a pristine -next tree so that we may compare our
>>> results from the same code base?
>>>
>>> Thanks,
>>>
>> Philippe,
>>
>> I went back to do a full git clone, checkout, patch, rebuild, and I
>> found that when I fetched the -next branch that the patch had been
>> comitted already.  So I proceeded to skip to the build step, and then
>> retest the simultaneous execution of two instances of the smokey
>> memory_pshared test, but still got the same failure.
>>
>> Are you seeing the test failure with your build?
> No, that is why I've asked for a confirmation actually.
>
>> I've never had any reason to doubt the validity of my SDK or build
>> procedures, but if your build is passing the test, something must be
>> wrong on my end.
>>
> Not necessarily, maybe I got lucky because of some setting. I'll follow
> up on this when I have tested more configurations.
>
Philippe,

I don't know if it was evident from some of the other emails we've
been exchanging, but I'm running on armv7a-neon, any possibility that
might be part of the problem?  32 vs. 64-bit maybe?