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

[Jonathan Larmour]

Christiaan Simons wrote:
> 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.

Generalised memory allocators only work sensibly with enough spare space 
left over that fragmentation is an infrequent occurence. Unlike the BSD 
kernel, lwIP users are unlikely to have the freedom of lots of space for 
the heap - quite the opposite. Maybe that's not too bad for PBUF_RAM 
allocations - apps can possibly handle not being able to send data for a 
little while (in the hope that more space will free itself later), but for, 
failures in, say, renewing a DHCP lease, you could lose your interface. And 
that could happen just because the SNMP agent was feeling a bit hungry with 
its own stuff. If there are more users, the problem compounds - a low 
priority subsystem can deprive a high priority subsystem of memory, either 
directly due to using it, or indirectly due to fragmentation.

Also in the above quote, the emphasis is on "good". The mem_malloc 
allocator is not "good". It is simple. This is only right in the context of 
lwIP. But it does not resist fragmentation in the way most other memory 
allocators endeavour to do (however it does avoid the larger code and space 
penalty).

> > 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.

Since pbufs can be chained, I'm not sure what you mean?

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

It entirely depends on the size of MEM_SIZE, compared with the allocation 
pressure.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine