накладные расходы для пустой динамической арены

struct malloc_state (он же mstate, он же дескриптор арены) имеет размер

glibc-2.2 (256+18)*4 байта =~ 1 КБ для 32-битного режима и ~2 КБ для 64-битного режима. glibc-2.3 (256+256/32+11+NFASTBINS)*4 =~ 1,1–1,2 КБ для 32-разрядной версии и 2,4–2,5 КБ для 64-разрядной версии

См. файл glibc-x.x.x/malloc/malloc.c, структура malloc_state.

Уничтожение арен... Пока не знаю, но есть такой текст (кратко - там написано НЕТ возможности уничтожения/урезания памяти ) из анализа http://www.citi.umich.edu/techreports/reports/citi-tr-00-5.pdf от 2000 г. (*немного устарел). Пожалуйста, назовите свою версию glibc.

Ptmalloc maintains a linked list of subheaps. To re-
duce lock contention, ptmalloc searchs for the first
unlocked subheap and grabs memory from it to fulfill
a malloc() request. If ptmalloc doesn’t find an
unlocked heap, it creates a new one. This is a simple
way to grow the number of subheaps as appropriate
without adding complicated schemes for hashing on
thread or processor ID, or maintaining workload sta-
tistics. However, there is no facility to shrink the sub-
heap list and nothing stops the heap list from growing
without bound. 

из malloc.c (glibc 2.3.5) строка 1546

/*
  -------------------- Internal data structures --------------------
   All internal state is held in an instance of malloc_state defined
   below. 
 ...
   Beware of lots of tricks that minimize the total bookkeeping space
   requirements. **The result is a little over 1K bytes** (for 4byte
   pointers and size_t.)
*/

Тот же результат, что и для 32-битного режима. Результат составляет чуть более 1 КБ.

Рассмотрите возможность использования TCmalloc из google-perftools. Он просто лучше подходит для поточных и долгоживущих приложений. И это очень БЫСТРО. Взгляните на http://goog-perftools.sourceforge.net/doc/tcmalloc.html, особенно для графики (чем выше, тем лучше). Tcmalloc вдвое лучше, чем ptmalloc.

В нашем приложении основной стоимостью нескольких арен была «темная» память. Память, выделенная ОС, на которую у нас нет ссылок.

Образец, который вы можете видеть,

Thread X goes goes to alloc, hits a collision, creates a new arena.
Thread X makes some large allocations.
Thread X makes some small allocation(s).
Thread X stops allocating.

Освобождаются большие ассигнования. Но вся арена на высшей отметке последнего активного в данный момент распределения по-прежнему использует VMEM, и другие потоки не будут использовать эту арену, если они не столкнутся с конкуренцией на основной арене.

По сути, это способствует «фрагментации памяти», поскольку память может быть доступна во многих местах, но необходимость расширения области не является причиной для поиска других областей. По крайней мере, я думаю, что причина в этом, дело в том, что ваше приложение может занять больше места на виртуальной машине, чем вы думаете. Это в основном поражает вас, если у вас ограниченный своп, поскольку, как вы говорите, большая часть этого в конечном итоге выгружается.

Наше (жадное до памяти) приложение может таким образом «тратить впустую» 10 процентов памяти, и в некоторых ситуациях это может сильно укусить.

Я не уверен, зачем вам создавать пустые арены. Если выделения и освобождения находятся в одном потоке друг с другом, то я думаю, что со временем вы будете стремиться к тому, чтобы все они находились в одной и той же области, специфичной для потока, без соперничества. У вас могут быть небольшие блики, пока вы туда добираетесь, так что, возможно, это причина.