Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28709

Re: Dynamic allocation and newlib-nano

Show all headers | View raw

On Thu, 27 Jun 2019 13:08:20 +0200, pozz wrote:

> I normally don't use dynamic allocation in embedded projects, however
> there are situations where this isn't possible.
> 
> I'm working on a project with LPC1768 Cortex-M3 MCU that features
> 32kB+32kB RAM. I'm using lwip+mbedTLS to make a TLS connection to AWS
> IoT Core through Ethernet.
> 
> After a precise allocation of data blocks (incoming Ethernet packets,
> outgoing packets and so on), it seems working. However I'm using dynamic
> allocation, mainly for outgoing packets: when some application (MQTT,
> DNS client, ...) wants to transmit, lwip requests some space from the
> heap.
> 
> lwip can be configured to use a set of memory pools of different sizes
> to avoid dynamic allocation, but it's very difficult to configure.
> During execution I saw allocation requests of very different sizes: 5-10
> bytes, 50-100 bytes, 800 bytes, 1500 bytes.
> 
> However the dynamic allocation algorithm appears very strange to me. I
> expected that malloc() returns always the start of the heap if the heap
> is completely free. It is so at the beginning, however when some
> allocations and deallocations happen, even if the heap is completely
> deallocated (all the allocations were freed), a new allocation doesn't
> return the start of the heap.
> How to explain this behaviour?
> 
> I noticed my allocation pattern is very simple and, after 1-5
> allocations, there are other 1-5 deallocations and I eventually have a
> completely free heap, when all the outgoing packets are serially shifted
> out and/or acked from the remote side.
> 
> For example:
> - malloc(3)=addr1 - free(addr1)   -> free heap - malloc(5)=addr2 -
> malloc(60)=add3 - free(addr2)
> - free(addr3)   -> free heap - malloc(800)=addr4 - malloc(5)=addr5 -
> malloc(32)=addr6 - free(addr5)
> - malloc(80)=addr7 - free(addr6)
> - free(addr7)
> - free(addr4)   -> free heap
> 
> With this pattern, I think I can simplify the allocation algorithm so
> that it returns always the start of the heap when it is completely free
> and reduce fragmentation of complex algorithm.

It could be trying to do a best fit algorithm.  Also depends if it's
trying to merge adjacent blocks.
Might try
malloc(3)
malloc(5)
free both
malloc(8)

But I suspect since there is still plenty of free space in the heap malloc
will take the quick way and alloc a new block.  It wont do the expensive
best fit or merge until it's out of space.

-- 
Chisolm
Republic of Texas

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 13:08 +0200
  Re: Dynamic allocation and newlib-nano upsidedown@downunder.com - 2019-06-27 14:42 +0300
    Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 15:59 +0200
      Re: Dynamic allocation and newlib-nano Niklas Holsti <niklas.holsti@tidorum.invalid> - 2019-06-27 17:47 +0300
        Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 18:37 +0200
          Re: Dynamic allocation and newlib-nano Niklas Holsti <niklas.holsti@tidorum.invalid> - 2019-06-27 21:23 +0300
            Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-28 11:38 +0200
        Re: Dynamic allocation and newlib-nano George Neuner <gneuner2@comcast.net> - 2019-06-27 17:02 -0400
  Re: Dynamic allocation and newlib-nano Joe Chisolm <jchisolm6@earthlink.net> - 2019-06-27 12:09 -0500
  Re: Dynamic allocation and newlib-nano Paul Rubin <no.email@nospam.invalid> - 2019-06-27 14:23 -0700
    Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-28 08:42 +0200

csiph-web