Cosmetic question (or maybe just out of curiosity). Thanks a lot! Markus
-------- Ursprüngliche Nachricht -------- Von: Christian Grothoff <groth...@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 issuewith malloc();2) the allocations can be large-ish, which may mean that malloc() wouldinternally 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 weallocate memorypools for say 32 (but generally configurable number of)connections in one larger mmap. Can you show any actual problems withthe current situation, or is this "cosmetic" because your pmap output islong-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 wishesMarkus