CODEWITHSUNDEEP
memory-managementembedded-linuxfragmentation
waffleman
waffleman

Reputation: 4339

Embedded Linux: Memory Fragmentation

In many embedded systems, memory fragmentation is a concern. Particularly, for software that runs for long periods of time (months, years, etc...). For many projects, the solution is to simply not use dynamic memory allocation such as malloc/free and new/delete. Global memory is used whenever possible and memory pools for types that are frequently allocated and deallocated are good strategies to avoid dynamic memory management use.

In Embedded Linux how is this addressed? I see many libraries use dynamic memory. Is there mechanism that the OS uses to prevent memory fragmentation? Does it clean up the heap periodically? Or should one avoid using these libraries in an embedded environment?

Upvotes: 2

Views: 5740

Answers (3)

baris.aydinoz
baris.aydinoz

Reputation: 1950

IMHO, in either case, you may search for memory allocation algorithms, which cause less fragmentation. And, configure this algorithm or your memory allocation implementation after measuring your memory requirements.

I can recommend TLSF as a start.

Upvotes: 1

KOkon
KOkon

Reputation: 646

That depends on how you use the memory.

Linux uses virtual memory for most cases, in which the application see the memory as a contiguous block of memory. The underlying kernel does all the manual mapping between the virtual memory and the physical memory, so that you don't have to deal with it. Physically, your memory might scatter around, but your applications don't see that.

Now, what if you really want contiguous physical memory? This often happen when you want to perform DMA, or some other hard requirements from your hardware. On that case, you are allowed to allocate memory page that points to specific physical memory. But you have to make this as an exception other than norm.

I designed my system in such a way that most driver (except "real-time" driver) on to the user space. That way you get all the benefits of the user space (more libraries, languages), don't kill the kernel if you have a bug, and utilizes the virtual memory available.

Upvotes: 2

EmeryBerger
EmeryBerger

Reputation: 3956

There is no non-moving memory allocator that can avoid fragmentation of at least a log(M/m) factor, where M = the size of the largest object request, and m = the size of the smallest (this is a classic result due to Robson, 1971).

I work with folks who do real-time systems programming (including at Airbus), and they studiously avoid the use of dynamic memory allocation, instead using pools, as you mention.

There is, however, a big difference between an OS and memory allocation. Dynamic memory allocation, as exposed to the programmer, is part of the library and has little to do with the OS (except as a source of memory). Linux itself uses a slab-based memory allocator for its own internal purposes; I assume Embedded Linux does the same, but am not sure.

Upvotes: 2

Related Questions