Re: [libmicrohttpd] mmap()

[Markus Doppelbauer]

Cosmetic question (or maybe just out of curiosity).

Thanks a lot!

Markus

-------- Ursprüngliche Nachricht --------

Von: Christian Grothoff <grothoff@gnunet.org>

Antwort an: libmicrohttpd development and user mailinglist <libmicrohttpd@gnu.org>

An: libmicrohttpd@gnu.org

Betreff: Re: [libmicrohttpd] mmap()

Datum: Thu, 10 Mar 2022 11:54:02 +0100

I see two (theoretical) benefits:

1) mmap cannot result in memory fragmentation, which could be an issue

with malloc();

2) the allocations can be large-ish, which may mean that malloc() would

internally fall back to mmap() anyway (of course depending on malloc()

and the actual size).

I'm not sure VRAM "pollution" by one map per concurrent connection is a

"real" issue. If it is, we could also consider a meta-pool where we

allocate memorypools for say 32 (but generally configurable number of)

connections in one larger mmap.  Can you show any actual problems with

the current situation, or is this "cosmetic" because your pmap output is

long-ish?

Happy hacking!

Christian

On 3/10/22 11:36, Markus Doppelbauer wrote:

Hello,

Is there some benefit using 'mmap()' in 'memorypool.c' instead 'malloc()'?

It somehow pollutes VRAM - inspecting with: `pmap -x <pid>`

(even if we have plenty of VRAM on x64)

Best wishes

Markus