Download to read offline
![thp defer+madvise defrag option (4.11)
• thp 割り当て失敗時の動作を制御する設定の追加
• always: その場で compaction する。thp 割り当て成功率が高
まるが、割り当て遅延が増大する。
• defer: 4kB ページ割り当てにフォールバックするが、裏で
kswapd/kcompactd を起動して後の thp 割り当ての成功率を
高める努力をする。
• never: 即 4kB ページ割り当てにフォールバックして何もしな
い。
• madvise: MADV_HUGEPAGE で指定したアドレス範囲の場合
だけ always 相当の動作 (その場で compaction) をし、それ
以外の場合は never 相当の動作をする。
• defer+madvise: MADV_HUGEPAGE で指定したアドレス範
囲の場合だけ always 相当の動作 (その場で compaction) を
し、それ以外の場合は defer 相当の動作をする。
# cat /sys/kernel/mm/transparent_hugepage/defrag
[always] defer defer+madvise madvise never](https://image.slidesharecdn.com/210320hugepagepublic-210320033301/85/Linux-hugepage-10-320.jpg)
Linux の hugepage の開発動向
- 1. Linux の hugepageの開発動向 堀口 直也 2021年 3月20日@Kernel/VM探検隊online part2
- 2. トピックス • hugepageの概要 (2分) • カーネルコミュニティの開発動向 (6 分)
- 3. hugepageの概要 (1) • 物理メモリ量の増大(~TB)、アプリケーションの巨大化が背景 • TLB の利用効率を上げる機能 (アドレス変換のキャッシュ効率) • 広いメモリ範囲を少ないキャッシュミスでアクセスできる。 pte mapping (4KB) pmd mapping (2MB) pud mapping (1GB) TLB Intel® 64 and IA-32 Architectures Software Developer's Manual Combined Volumes 3
- 4.
- 5. hugepageの概要 (3) • Linuxの実装 • hugetlb (2002~) • 専用のメモリプールを管理し、そこからプロセスに割り当てて使う。 • 動作の予測がしやすい。 • アプリケーションは意識して利用する必要がある (libhugetlbfs のライブラリ支援)。 • thp (= transparent hugepage) (2011~) • 4kB メモリ管理と多くのコードを共有する。 • 汎用性が高いが、コードが複雑で動作を予想しにくい。 • アプリケーションは意識せず使える (意識した方がよいこともある) • split: メモリ管理処理の中で thp のまま扱えないときに、thp を 4kB ページに分解する。 • collapse: khugepaged が裏でメモリをスキャンして連続空きメモリを探し、使用中の 4kB ページを thp に変換する。 • 注) • hugetlb と thp は独立の機能 (同一システムで同時に使用することもできるが、 連携はしない) • カーネルコミュニティでの呼び方も曖昧で、文脈で明らかに分かる場合は単に “hugepage” と呼ばれる。 • 代表的なユースケース • 仮想化基盤 • hugetlb, thp ともに使用されている。 • データベース • hugetlb は広く使用されている。 • thp は複雑なワークロードで能力が発揮できないため、現状オフにして運用される ことが多い。
- 6. カーネルコミュニティの開発動向 • hugetlb • hugetlbcgroup (3.6) • hugetlb: MAP_HUGETLB/SHM_HUGETLB (3.10) • hugepage migration (3.12) • page fault scalability (3.15) • runtime gigantic (1GB) page allocation (3.16) • min_size mount option (4.1) • MADV_REMOVE (4.3) • O_TMPFILE support (5.5) • hugetlb cgroup が cgroup v2 対応 (5.6) • Free some vmemmap pages of HugeTLB page (5.13~?) • thp • メイン機能 (2.6.38) • huge zero page (3.8) • khugepaged policy support (3.13) • thp page cache support (4.8, 5.9~?) • thp defer+madvise defrag option (4.11) • thp swap (4.13, 4.14) • thp migration for mempolicy (4.14, 4.17) • compaction 効率 (thp allocation 成功率) 改善 (5.1) • text section の thp 対応 (5.4) • NUMA 割当優先順の改善 (性能問題改善) (5.4) • khugepaged の collapse 成功率改善 (5.8) • 他 • DAX support huge page fault for ext4/XFS (4.3) • 各種情報採取 (procfs) • x86 以外の arch https://kernelnewbies.org/LinuxVersions
- 7. min_size mount option(4.1) • hugetlb subpool • hugetlbfs のマウントごとのプール管理 • global pool (struct hstate) はマウント間で共有される。 • min_size マウントオプションにより、そのマウントで最低限 利用が保証される hugepage 数を指定できる (単位をつけて バイト数指定やパーセント指定も可能)。 global pool hugetlbfs on /mnt/hugetlb1 hugetlbfs on /mnt/hugetlb2 subpool subpool struct hugepage_subpool { spinlock_t lock; long count; long max_hpages; /* Maximum huge pages or -1 if no maximum. */ long used_hpages; /* Used count against maximum, includes */ /* both alloced and reserved pages. */ struct hstate *hstate; long min_hpages; /* Minimum huge pages or -1 if no minimum. */ long rsv_hpages; /* Pages reserved against global pool to */ /* sasitfy minimum size. */ }; struct hstate { int next_nid_to_alloc; int next_nid_to_free; unsigned int order; unsigned long mask; unsigned long max_huge_pages; unsigned long nr_huge_pages; unsigned long free_huge_pages; unsigned long resv_huge_pages; unsigned long surplus_huge_pages; unsigned long nr_overcommit_huge_pages; ... mount –t hugetlbfs –o pagesize=2M,size=100,min_size=10 none /mnt/hugetlb1
- 8. Free some vmemmappages of HugeTLB page (5.13~?) • vmemmap page = struct page を格納する領域 • 物理メモリの 1.6% 程度を常に占有している。 • hugepage の使用中は、vmemmap page を一時的に解放できる。 • 先頭数ページ以外は struct page の内容が同一なので。 • 2MB hugepage の場合 6 ページ分節約 • 1GB hugepage の場合 4094 ページ分節約 • マージされる雰囲気はあったが、数日前に延期が決まった。 • hugepage 解放処理が atomic context かどうかで分岐していたこと にコアメンテナが異論を唱えた。 • 先に hugepage の割り当て・解放処理の rework が必要となった。 https://lore.kernel.org/linux-mm/20210308102807.59745-1-songmuchun@bytedance.com/ HugeTLB struct pages(8 pages) page frame(8 pages) +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ | | | 0 | -------------> | 0 | | | +-----------+ +-----------+ | | | 1 | -------------> | 1 | | | +-----------+ +-----------+ | | | 2 | ----------------^ ^ ^ ^ ^ ^ | | +-----------+ | | | | | | | | 3 | ------------------+ | | | | | | +-----------+ | | | | | | | 4 | --------------------+ | | | | 2MB | +-----------+ | | | | | | 5 | ----------------------+ | | | | +-----------+ | | | | | 6 | ------------------------+ | | | +-----------+ | | | | 7 | --------------------------+ | | +-----------+ | | | | | | +-----------+
- 9. thp page cachesupport (4.8~) • 従来 thp は anonymous page に対してしか使えなかった のをページキャッシュでも使えるようにする試み。 • ページの split とマッピングの split を分離 • thp として使うか 4kB ページとして使うか、をプロセス単位で決め たい。 • pmd マッピングと pte マッピングが共存できる (double mapping)。 • struct page の参照カウントの rework • 今まで thp の参照カウントは先頭ページが代表して上げ下げしていたの が、各 subpage ごとの管理に変更 • XArray: ページキャッシュのデータ構造の改善 • multi index entry: インデックス幅をポインタに紐付ける。 • tmpfs/shmem は対応済み • ext4/XFS のサポート (開発中) プロセス1 プロセス2 pmd pte pmd 物理メモリ thp
- 10. thp defer+madvise defragoption (4.11) • thp 割り当て失敗時の動作を制御する設定の追加 • always: その場で compaction する。thp 割り当て成功率が高 まるが、割り当て遅延が増大する。 • defer: 4kB ページ割り当てにフォールバックするが、裏で kswapd/kcompactd を起動して後の thp 割り当ての成功率を 高める努力をする。 • never: 即 4kB ページ割り当てにフォールバックして何もしな い。 • madvise: MADV_HUGEPAGE で指定したアドレス範囲の場合 だけ always 相当の動作 (その場で compaction) をし、それ 以外の場合は never 相当の動作をする。 • defer+madvise: MADV_HUGEPAGE で指定したアドレス範 囲の場合だけ always 相当の動作 (その場で compaction) を し、それ以外の場合は defer 相当の動作をする。 # cat /sys/kernel/mm/transparent_hugepage/defrag [always] defer defer+madvise madvise never
- 11. thp swap (4.13,4.14) • 従来 thp が swap 対象になったとき、split してから 4kB 単位で swap out/in していたのを、thp 単位で swap out/in できるようになる。 • swapcache や swap デバイス管理、IO などがバッチ 化されるため swap 性能が改善する。 • メモリフラグメンテーションの回避や thp の利用率向 上につながる。
- 12. 各種情報採取 • thp # grep-e thp -e huge /proc/vmstat nr_shmem_hugepages 0 nr_file_hugepages 0 nr_anon_transparent_hugepages 6 numa_huge_pte_updates 141 thp_migration_success 268538 thp_migration_fail 949 thp_migration_split 0 thp_fault_alloc 1313387 thp_fault_fallback 6 thp_fault_fallback_charge 0 thp_collapse_alloc 121340 thp_collapse_alloc_failed 584 thp_file_alloc 80 thp_file_fallback 0 thp_file_fallback_charge 0 thp_file_mapped 276 thp_split_page 80272 thp_split_page_failed 169409 thp_deferred_split_page 269855 thp_split_pmd 562425 thp_split_pud 0 thp_zero_page_alloc 0 thp_zero_page_alloc_failed 0 thp_swpout 36 thp_swpout_fallback 0 # cat /proc/PID/smaps ... 700000000000-700000200000 rw-s 00000000 00:2f 2 /tmp/shmem/testfile Size: 2048 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 2048 kB Pss: 2048 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 2048 kB Referenced: 2048 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB // 2.6.38 以降 ShmemPmdMapped: 2048 kB // 4.8 以降 FilePmdMapped: 0 kB // 4.8 以降 Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 1 // 5.0 以降 ProtectionKey: 0 VmFlags: rd wr sh mr mw me ms sd # cat /proc/meminfo ... AnonHugePages: 12288 kB // 2.6.38 以降 ShmemHugePages: 0 kB // 4.8 以降 ShmemPmdMapped: 0 kB // 4.8 以降 FileHugePages: 0 kB // 5.4 以降 FilePmdMapped: 0 kB // 5.4 以降 ...
- 13. 各種情報採取 • hugetlb # cat/proc/PID/numa_maps … 7f4dc1200000 default file=/anon_hugepage040(deleted) huge anon=1 dirty=1 N3=1 kernelpagesize_kB=2048 7fff335f0000 default stack anon=3 dirty=3 N3=3 kernelpagesize_kB=4 // 3.20 以降 7fff3369d000 default mapped=1 mapmax=35 active=0 N3=1 kernelpagesize_kB=4 # cat /proc/meminfo ... AnonHugePages: 12288 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 48 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 48 Hugepagesize: 2048 kB Hugetlb: 98304 kB // 5.12 以降 DirectMap4k: 1145048 kB DirectMap2M: 27863040 kB DirectMap1G: 1191182336 kB # cat /proc/PID/smaps ... 700000000000-700000400000 rw-p 00000000 00:0e 44339 /anon_hugepage (deleted) Size: 4096 kB KernelPageSize: 2048 kB MMUPageSize: 2048 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB // 4.4 以降 Private_Hugetlb: 4096 kB // 4.4 以降 Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 0 VmFlags: rd wr mr mw me de ht sd # grep htlb /proc/vmstat htlb_buddy_alloc_success 15698 htlb_buddy_alloc_fail 0
- 14. x86 以外の arch •Arm hugepage support (hugetlb/thp 同時) (3.11) • S/390 2G hugetlb support (4.8) • SPARC 2G hugetlb support (4.11) • ppc64 hugetlb migration (4.13) • ppc64 1GB hugetlb support (4.13) • arm64 hugetlb migration (5.1) • MIPS64 hugetlb support (5.1) • RISC-V hugetlb support (5.3) • powerpc: Support 16k hugepages with 4k pages (5.10) • s390/mm: add support to allocate gigantic hugepages using CMA (5.11)
- 15. さいごに • hugepage の概要と最近の開発動向について紹介しま した。 •雑多な内容でしたが、知っておくこと効率よいアプリ ケーションを書く助けになるかもしれません。 • データベース等を開発される方は hugepage 利用時の具体的 課題を共有していただけれると嬉しいです。 • linux-mm コミュニティとカーネル開発に参加したいという方 は、ご相談もらえれば何かお手伝いできるかもしれません。 • E-mail: nao.horiguchi@gmail.com • Twitter: @nhoriguchi • GitHub: Naoya-Horiguchi
- 16.
- 17. page fault scalability(3.15) • hugetlb 用のページフォルトハンドラが、global mutex で排他されていたのを、ハッシュテーブル mutex に変更して並列性を上げた。 • データベースなど、多数のhugepageを使用するアプリ ケーションの初期化速度を改善できる。
- 18. runtime gigantic (1GB)page allocation (3.16) • 古いカーネルでは、1GB hugepage を使うにはシステ ム起動時に静的に割り当てる必要があり、起動後は hugepage の数を変更できなかった。 • この方式は NUMA 非対応で、ノードを指定して hugepage を割り当てることもできなかった。 • 3.16 でこれらの課題は解決され、2MB hugepage と同 様 sysfs からプールのサイズを変更できる。 • メモリ負荷が高い状況では 1GB の連続メモリ領域が たまたま空いていることは期待できない。 • システム起動直後に割り当てるのがよい。 • page migration 頼み hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=... echo 4 > /sys/devices/system/node/node1/hugepages/hugepages-1048576kB/nr_hugepages