De ce un proces a alocat multe memorie de pagini care nu sunt uriașe folosind biblioteca jemalloc când pagina transparentă uriașă a fost activată?

Am activat o pagină uriașă transparentă într-un proces care utilizează jemalloc pentru alocarea memoriei, urmând pașii următori:

1. setarea unei stări transparente a paginii uriașe la „madvice”:

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

2.setarea jemalloc pentru a folosi întotdeauna thp

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

Deoarece programul folosește doar jemalloc pentru a aloca memorie, rezultatul așteptat ar trebui să fie că dimensiunea memoriei utilizate în totalitate (RSS) este egală cu dimensiunea paginilor uriașe alocate. Dar diferă foarte mult, așa cum arată elementele „AnonHugePages” și „Rss” de mai jos:

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

Știu că alocarea normală a memoriei (pagină de 4k) va avea loc dacă nu există o pagină destul de mare disponibilă în sistemul de operare, adăugând un număr la elementul „thp_fault_fallback” din „/proc/vmstat”. Dar valoarea este mică, așa cum arată fragmentul de mai jos, ceea ce înseamnă că nu se întâmplă atât de multă alocare de pagini care nu sunt uriașe:

# grep thp_fault_fallback /proc/vmstat 
thp_fault_fallback 2982

Deci, de ce diferența dintre dimensiunea RSS și THP? Aștept cu nerăbdare câteva indicii și sfaturi.