[riot-devel] Oneway-Malloc

Sam Kumar samkumar99 at gmail.com
Tue Aug 9 22:15:25 CEST 2016

I didn't realize that the reason that one-way malloc was left one-way was
that dynamic memory allocation is discouraged. I suppose I should leave it
that way if that is the case.

Let me give you some context for what I am working on. I am working on
implementing a TCP stack for RIOT. I am aware of the work being done in
Pull Request #4744. The work I am doing to be a more feature-complete
alternative to the work being done in #4744, aimed at those platforms that
have the resources to support it. It is port of the protocol logic in the
FreeBSD operating system, and would have support for zero-window probing,
out-of-order segment reassembly, TCP timestamps, New Reno congestion
control, selective acknowlegements (SACK), etc. I've already done the work
to port this to TinyOS, and found that the memory overhead was ~20KB of
code memory total and ~550 bytes of RAM per socket, which can reasonably be
supported on some platforms.

I am aware that other parts of RIOT OS use zone allocators. The allocator
for file descriptors, and the packet buffer for allocating pktsnips, are
two that I have been working with. In fact, I have already been trying to
avoid dynamic memory allocation (I allocate the TCP state and SACK blocks
from pools, for instance).

I was interested in using dynamic memory allocation for the send buffer on
TCP sockets. It seems wasteful to statically allocate 1-2 KB buffers for
each TCP socket when most applications won't even need to use the whole
thing. Rather, I wanted to make the send buffer grow as the user writes
data to the socket--up to a limit, when writes start blocking. If I run out
of heap space while doing this, I can just make the user block on the
socket write, just as if they had filled the buffer. Using a pool or zone
seems to defeat the purpose, in this case, since that would require me to
allocate a static region large enough to accommodate the full size of all
the send buffers upfront, which is precisely what I was trying to avoid.

Just wanted to explain where I am coming from. I suppose I could make do
with a static pool of memory and allocate memory from it, if dynamic memory
allocation really must be avoided anywhere in the kernel. Thanks for the


On Tue, Aug 9, 2016 at 12:27 PM, Oleg Hahm <oliver.hahm at inria.fr> wrote:

> Hi Sam!
> On Tue, Aug 09, 2016 at 12:01:08PM -0700, Sam Kumar wrote:
> > I noticed that there is a "oneway-malloc" module in RIOT OS. It appears
> to
> > be a thin wrapper around sbrk that only supports allocating memory, not
> > freeing it.
> This is correct. It was originally introduced for MSP430 platforms.
> > I am doing some development using RIOT OS, and dynamic memory allocation
> > would be useful to me. Is there already a module that implements dynamic
> > memory allocation suitable for general-purpose use in the kernel and in
> > user programs?
> Dynamic memory allocation is usually a bad idea for embedded systems (see
> for
> instance https://www.quora.com/Why-is-malloc-harmful-in-embedded-systems).
> Within kernel context it MUST be completely avoided.
> If you really need dynamic memory allocation, you can either use the TLSF
> package [1] or use a simple memory manager that uses a static memory pool
> like
> memmgr [2]. TLSF is O(1), but works only on 32 bit platforms.
> > If such a module does not already exist, I am willing to contribute a
> > lightweight implementation of malloc, realloc, calloc, and free to
> replace
> > the oneway-malloc module.
> This could be a good idea indeed. :) I once had the above cited memmgr as
> package in one of my private branches, but I guess I haven't pushed it to
> Github. However, creating this package didn't take longer than half an
> hour.
> Cheers,
> Oleg
> [1] https://github.com/RIOT-OS/RIOT/tree/master/pkg/tlsf
> [2] https://github.com/eliben/code-for-blog/tree/master/2008/memmgr
> --
> The worst thing about Perl jokes is that next morning you can't understand
> why
> they seemed so funny.
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20160809/300ab3e8/attachment-0001.html>

More information about the devel mailing list