search

tass-belgium / picotcp

PicoTCP is a free TCP/IP stack implementation
Other
1.19k stars 219 forks source link

Memory manager cannot allocate more than 1600 bytes at once #410

Open matthiasvp opened 8 years ago

matthiasvp commented 8 years ago

When using the internal memory manager it is not possible to allocate more than PICO_MAX_SLAB_SIZE(which is 1600) bytes at once, is this done on purpose or should this be fixed?

frederikvs commented 8 years ago

This was probably done with the idea that ethernet packets are the largest thing we'd have to allocate. As you found out however, allocating a lot of timers (I think you mentioned 66 or something?) requires a larger block.

Since the memory allocator isn't used all that often outside of a testing context, and 66 timers are already quite a lot, I don't think it's urgent that we look at this. But we should be aware of it, and track it in this issue.

thanks for reporting

frederikvs commented 8 years ago

After we fixed #409, this issue is causing Jenkins to fail. During one of the tests with the memory manager, we start a background process which uses way too many timers, and eventually does an exit(-1) because it can't exit cleanly (that would require yet another timer). Before the fix of #409, the status code of this background process was simply thrown away, with the fix it kills the autotest script.

Looking for a fix or a workaround for that.

danielinux commented 8 years ago

@frederikvs are you still struggling with the too-many-timers issue here and there? I've committed a new heap.h yesterday in the ebihta repo, and it's possible to delete elements from the heap now (O(n), though). You may want to have a look at the new heap.h. Watch out for the heap_insert function though, the return value has changed to allow the caller to store the id to be used in the delete operation. See the README.md for more details.

frederikvs commented 8 years ago

thanks for the input @danielinux . I've actually been working on a fix myself, but I didn't have the time today to finish it. Just a couple of wrinkles to work out, normally tomorrow. It involves splitting up the heap over a number of blocks, with a maximum size per block (compile-time constant). When I finish that, we can compare and see which is the better solution :-)