Почему процесс выделил много памяти, не относящейся к огромным страницам, с помощью библиотеки jemalloc, когда была включена прозрачная огромная страница?

Я включил прозрачную огромную страницу в процессе, который использует jemalloc для выделения памяти, выполнив следующие действия:

1. установка прозрачного огромного состояния страницы на «madvice»:

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled;
echo madvise > /sys/kernel/mm/transparent_hugepage/defrag;

2. установка jemalloc, чтобы всегда использовать thp

экспорт MALLOC_CONF="thp:всегда,metadata_thp:всегда,dirty_decay_ms:-1";

Поскольку программа использует jemalloc только для выделения памяти, ожидаемый результат должен состоять в том, что размер используемой памяти полностью (RSS) равен размеру выделенных огромных страниц. Но он сильно отличается, как показано ниже в пунктах «AnonHugePages» и «Rss»:

# cat /proc/<pid>/smaps |awk 'NF==3 {dict[$1]+=$2} END{for(key in dict) print key" "dict[key]}' 
Заблокировано: 4
Shared_Clean: 18732
MMUPageSize: 8776
Размер ядра: 8776
ПС: 150242778
Своп: 0
ШмемПмдМаппед: 0
Shared_Dirty: 0
Размер: 258068324
Private_Hugetlb: 0
Private_Dirty: 150234008
ЛенивыйБесплатно: 0
Private_Clean: 124
Ссылка: 147993656
Вмфлаги: 0
AnonHugePages: 76193792
RSS: 150252864
SwapPss: 0
Shared_Hugetlb: 0
Аноним: 150232456

Я знаю, что обычное выделение памяти (страница 4 КБ) произойдет, если в операционной системе не будет достаточно большой страницы, добавляя один счетчик к элементу «thp_fault_fallback» в «/proc/vmstat». Но значение невелико, как показано в приведенном ниже фрагменте, а это означает, что не происходит такого большого распределения страниц:

# grep thp_fault_fallback /proc/vmstat 
thp_fault_fallback 2982

Итак, почему разрыв между размером RSS и THP? Ждем подсказок и советов.