Вы, наверное, слишком много пишете последнее время, и код через чур сложный, а уже конец года, это всё равно что релизить ночью в пятницу...

Куча сама "дефрагментируется" https://www.opennet.ru/openforum/vsluhforumID3/122777.html#250
и возможно намудрить с последовательностью alloc() free() так, что слияние при освобождении части кучи окажется невозможным. На это и был намёк у меня изначально. Но я не заявлял, что являюсь менеджером кучи и буду дефрагментировать за него. Если хотите, что бы именно "дефрагментация" было написано, извольте, тоже про память:

/*
* The defrag ratio allows a configuration of the tradeoffs between
* inter node defragmentation and node local allocations. A lower
* defrag_ratio increases the tendency to do local allocations
* instead of attempting to obtain partial slabs from other nodes.
*
* If the defrag_ratio is set to 0 then kmalloc() always
* returns node local objects. If the ratio is higher then kmalloc()
* may return off node objects because partial slabs are obtained
* from other nodes and filled up.
*
* If /sys/kernel/slab/xx/remote_node_defrag_ratio is set to 100
* (which makes defrag_ratio = 1000) then every (well almost)
* allocation will first attempt to defrag slab caches on other nodes.
* This means scanning over all nodes to look for partial slabs which
* may be expensive if we do it every time we are trying to find a slab
* with available objects.
*/

/*
* By default, transparent hugepage support is disabled in order to avoid
* risking an increased memory footprint for applications that are not
* guaranteed to benefit from it. When transparent hugepage support is
* enabled, it is for all mappings, and khugepaged scans all mappings.
* Defrag is invoked by khugepaged hugepage allocations and by page faults
* for all hugepage allocations.
*/