[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [task #7890] Review heap usage
From: |
Simon Goldschmidt |
Subject: |
[lwip-devel] [task #7890] Review heap usage |
Date: |
Tue, 21 Apr 2009 19:54:38 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 |
Update of task #7890 (project lwip):
Priority: 5 - Normal => 3 - Low
_______________________________________________________
Follow-up Comment #1:
Remaining users of heap (that cannot be configured to use statically
allocated memory) are:
- netdb (16, 36 or 'namelen' of bytes -> 16 up to ~1460 bytes?)
- snmp (16, 32, 28, value_len, array-of-u32_t, len(u8_t) -> anything between
1 and 255 bytes)
- autoip (10 bytes)
- dhcp (? 1 up to ~1460 bytes?)
So, all in all, we have only few occurrences left. I can live with netdb, but
the downside is that for dhcp and snmp, the maximum size is unknown.
For dhcp (since boot_file_name is currently unused (why?)), it would be
enough to have a netif_dhcp which reserves space for a struct dhcp, the
maximum size of options_in and dhcp_msg.
However, for snmp, I'm not sure :-(
Note that I am not interested in 'allocate-once-on-startup' allocations but
only in 'runtime-alloc-and-free' allocations to be able to minimize the heap
size without risking fragmentation.
To regard this as fixed, we can either
- live with all the heap going into statically allocated pools or
- solve dhcp and dig into snmp a bit or
- a bit of both
Is there anyone interested in this except for me? ;-)
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/task/?7890>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-devel] [task #7890] Review heap usage,
Simon Goldschmidt <=