lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kieran Mansley
Subject: Re: [lwip-users] mem_malloc(): memory fragmentation
Date: Mon, 23 Oct 2006 14:00:28 +0100

On Mon, 2006-10-23 at 13:42 +0100, Jonathan Larmour wrote:
> Goldschmidt Simon wrote:
> > maybe a better solution might be to implement 
> > mem_malloc() as different pools and leave the PBUF_RAM implementation 
> > since it would be allocated from pools then.
> 
> Note that despite what's implied in that bug, IMHO you can't actually let 
> it be the current pbuf_alloc(..., PBUF_POOL), otherwise if you use up all 
> the pbufs with TX data, you won't have room for any RX packets, including 
> the TCP ACK packets which will allow you to free some of your TX packets. 
> So either RX and TX packets should be allocated from different pools, or 
> there should be a low water mark on the pool for TX allocations in order to 
> reserve a minimum number of packets for RX.

The later would be my preference as it is much more efficient on memory
usage where you have unidirectional traffic (which is, to a first
approximation, quite common for bulk transfers).

> One good solution if using 2^n sized pools is to use a buddy allocator[1] 
> to divide up larger contiguous space, so it may not be as wasteful as you 
> think. One difference with a normal buddy allocator is that a normal one 
> would normally e.g. return a 2Kbyte buffer if you request 1025 bytes. An 
> lwIP implementation could work for maximum efficiency instead and allocate 
> that as a 1024 byte buffer plus a 64 byte buffer (or whatever the lowest 
> granularity would be) chained together.

I think that would definitely be the only way such a change would be
acceptable given that lwIP tries to have a low memory footprint, and
indeed it's the only way I'd even though of it being done.

> But all this would be a non-trivial bit of coding so I'm sure people would 
> be grateful if you have time to do it 

Exactly.  These day changes to lwIP generally only get included by
someone who uses it taking the time to write the code - the maintainers
do their best to maintain it and fix bugs, but a rework such as this is
unlikely to ever reach the top of their list of things to do.

> I could also believe the result will use more a fair bit more code space 
> than the present mem_malloc.

Certainly true.

Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]