[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] why
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] why |
Date: |
Thu, 4 Mar 2021 11:29:41 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
There are various benefits:
1) forcing the use of mmap() -- and uniform sizes for all requests --
ensures that we don't suffer from memory fragmentation, which is what
would happen if we allocate lots of different-sized tiny bits based on
say HTTP request headers;
2) using our per-request pool ensures that a request will not consume
more memory than granted, without us having to track the amount of libc
allocations made;
3) it avoids having to deal with deallocation of individual (smaller)
bits, we can just blow away all allocations made per-request in one big
swoop. This is less code and faster.
4) pointer-bumping allocation is faster than traditional malloc/free;
5) we use a particularly tricky variant with allocation from bottom and
from the top of the area, with the middle being the 'free' range, so we
_can_ not only do pointer-bumping allocation but in some cases also
pointer-bumping *deallocation* for the IO buffer.
So in short: faster, simpler, safer.
-Christian
On 3/4/21 11:15 AM, folkert wrote:
> Hi,
>
> While going through the libmicrohttpd sources, I noticed this part in
> daemon.c:
>
> /* Allocate memory pool in the processing thread so
> * intensively used memory area is allocated in "good"
> * (for the thread) memory region. It is important with
> * NUMA and/or complex cache hierarchy. */
> connection->pool = MHD_pool_create (daemon->pool_size);
>
> I'm curious why libmicrohttpd is doing its own memory management.
> If I remember correctyl the memory allocater of glibc has pools of
> memory per thread? It does keep freed() memory in a per-thread list
> before it is moved to the global pool of free memory.
>
>
> Regards.
>