当启用透明大页时,为什么进程使用jemalloc库分配了许多非大页内存?



我在一个使用jemalloc进行内存分配的进程中启用了透明巨页,步骤如下:

  1. 设置透明巨幅页面状态为"madvice":
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled;
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag;

2。设置jemalloc总是使用

export MALLOC_CONF="thp:always,metadata_thp:always,dirty_decay_ms:-1";

由于程序只使用jemalloc来分配内存,因此预期的结果应该是全部使用的内存大小(RSS)等于所分配的大页面的大小。但它有很大的不同,因为items "AnonHugePages"one_answers";Rss"如下所示:

# cat /proc/<pid>/smaps |awk 'NF==3 {dict[$1]+=$2} END{for(key in dict) print key" "dict[key]}' 
Locked: 4
Shared_Clean: 18732
MMUPageSize: 8776
KernelPageSize: 8776
Pss: 150242778
Swap: 0
ShmemPmdMapped: 0
Shared_Dirty: 0
Size: 258068324
Private_Hugetlb: 0
Private_Dirty: 150234008
LazyFree: 0
Private_Clean: 124
Referenced: 147993656
VmFlags: 0
AnonHugePages: 76193792
Rss: 150252864
SwapPss: 0
Shared_Hugetlb: 0
Anonymous: 150232456

我知道如果操作系统中没有足够大的可用页面,将会发生正常的内存分配(4k页),在项&;thp_fault_fallback&;中添加一个计数。在"/proc/vmstat"。但是这个值很小,如下面的代码片段所示,这意味着不会发生那么多非huge-page分配:

# grep thp_fault_fallback /proc/vmstat 
thp_fault_fallback 2982

那么,为什么RSS和THP的大小存在差距呢?期待一些线索和建议。

原因已找到:https://github.com/jemalloc/jemalloc/issues/2099.

相关内容

  • 没有找到相关文章

最新更新