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
