Re: [lwip-users] mem_malloc(): memory fragmentation

[Christiaan Simons]

Simon,

> My question is: has anyone ever bothered to somehow avoid using a
> heap and using pools instead?

Can remember being a bit conservative about using mem_malloc for
24/7 use myself. Most literature about RT systems is quite biased againsed
malloc for many good reasons. However you shouldn't be too frightened by
mem_malloc fragmentation unless you have a malloc which performs
very poor in this respect.

We had this discussion before on this list and frankly I'm not a bit afraid
using malloc for non/soft RT, 24/7 sytem stuff now. You'll certainly
run into other troubles when trying to avoid it to great lengths.

Let's quote (and learn from) McKusick and Karels (from the BSD kernel
malloc paper):

"A generalized memory allocator is needed to reduce the complexity of
writing code inside the kernel.
Rather than providing many semi-specialized ways of allocating memory, the
kernel should provide a single
general purpose allocator. With only a single interface, programmers do not
need to figure out the most
appropriate way to allocate memory. If a good general purpose allocator is
available, it helps avoid the syndrome
of creating yet another special purpose allocator."

Search'n'replace "kernel" with "lwip" and you get my point.
Too many hackers here, with too many good ideas for their own lwIP setup,
I'm afraid.

> I would favor solving this problem by 'fixing' savannah bug #3031
> submitted by Leon Woestenberg, which basically proposes getting rid
> of PBUF_RAM and using pools instead.

Different issue. #3031 is nice to have, and may solve some other odd
corners.
Doesn't solve fragmentation.

I'm open for  fragmentation test results and test cases for our
mem_malloc() though...

Christiaan Simons

Hardware Designer
Axon Digital Design

http://www.axon.tv