[Top][All Lists]
[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