Xenomai 4 Allocator Fragmentation Questions

Kevin Strell <[email protected]> Tue, 14 Jul 2026 16:44:19 -0400
Newsgroups dev.linux.lists.xenomai
Message-ID <CADfsJ_GwXvHioDB_HvGWardrTj_wFJJO-q0QtER42duwZFoi9Q@mail.gmail.com>
We are currently using Xenomai 4 on an AM69 on our new prototype and
appear to be running into fragmentation issues with the default
allocator while trying to use thread local heaps. After several
seconds of operation our application starts experiencing allocation
failures with evl_alloc_block_unlocked returning NULL. Our heaps are
allocated on reset and we do not extended or otherwise change the size
of the heaps during runtime. The allocated memory in question is
allocated out-of-band and is typically under 100 bytes but
occasionally there are larger allocations. Additionally, we have tried
running the heap_torture test on our platform and the results do not
seem good. Pretty much every test with the +shuffle option is showing
more than 50% fragmentation and many show more than 90%.

We did try the compaction procedure documented on the Xenomai 4
Caveats page but it did not seem to improve our situation. It is
unclear to us when the compaction should be triggered. The
documentation states it needs to happen before mlockall() is called
but evl_init() makes a call to mlockall() and the latter seems like it
needs to be called first.

We have been able to avoid the fragmentation problems by switching to
using the rpmalloc library (https://github.com/mjansson/rpmalloc)
instead of libevl's memory heap services. All that being said, we have
a couple questions about the default Xenomai allocator.

1. Other than the compaction procedure, is there anything we can do
with the default Xenomai allocator to improve the performance in
regards to fragmentation?
2. When is the correct time to run the compaction procedure in regards
to when we should call evl_init()?
3. If the fragmentation is a known issue of the default allocator, is
there any other allocator that is recommended?

Regards,
Kevin Strell