Re: Xenomai 4 Allocator Fragmentation Questions

[Philippe Gerum <rpm@xenomai.org>]

Kevin Strell <kstrell@aerotech.com> writes:

> We have been able to avoid the fragmentation problems by switching to
> using the rpmalloc library (https://github.com/mjansson/rpmalloc)

A note regarding this allocator, which documentation reads as follows
under the "Worst case scenarios" section:

"Since each heap maps a span of memory pages per page type, a thread
that allocates just a few blocks of each size class (16, 32, ...) for
many size classes will commit a memory page for each used size class,
while only using a small fraction of the committed memory. However,
memory pages are committed on demand and blocks are initialized only as
needed, ..."

Assuming that "committing pages" may mean mapping them to the current
address space and/or performing some kind of memcontrol work (msync?),
you may want to make sure that rpmalloc can pre-commit pages, so that
this does not happen in time-critical work loops. Because rpmalloc
operates on a per-thread basis, you would need to ensure this for each
thread attached to the evl core specifically. Failing to do so would
certainly cause those real-time threads to be demoted to the in-band
stage. You may want to check this using the related health monitoring
service [1] (EVL_HMDIAG_SYSDEMOTE).

To sum up, rpmalloc addresses the fragmentation issue by dedicating each
memory page to dealing with a particular block size, for allocation
_and_ release, so it does not have to resort to dynamic garbage
collection. However, in order to meet real-time requirements, you may
want to make sure that alloc and release operations won't ever issue a
regular system call under the hood.

[1] https://v4.xenomai.org/core/user-api/thread/index.html#health-monitoring

-- 
Philippe.