論⽂輪読: Coordinated and Efficient

Huge Page Management with Ingens (OSDIʼ16)

2017/1/4 1

OSDIʼ16 : Operating Systems I

• Push-Button Verification of File Systems via Crash Refinement

• Intermittent Computation without Hardware Support or Programmer Intervention

• Machine-Aware Atomic Broadcast Trees for Multicores

• Light-Weight Contexts: An OS Abstraction for Safety and Performance

2017/1/4 2

OSDIʼ16 : Operating Systems II

• CertiKOS: An Extensible Architecture for Building Certified Concurrent OS Kernels

• EbbRT: A Framework for Building Per-Application Library Operating Systems

• SCONE: Secure Linux Containers with Intel SGX

• Coordinated and Efficient Huge Page Management with Ingens

2017/1/4 3

Coordinated and Efficient Huge Page Management with Ingens• Youngjin Kwon, Hangchen Yu, and Simon Peter, Emmett

Witchel, The University of Texas at Austin• Christopher J. Rossbach, The University of Texas at Austin

and Vmware• OSDIʼ16 Operating System Session

• LinuxのTransparent Huge Page(THP) の機構が雑

• THPの5つの問題を指摘し，それぞれに対する解決策の提案, 実装, 評価

2017/1/4 4

Page Table (IA-32e) : 4-Kbyte (base page)

2017/1/4 5

- Offset : 12bit = 4KB

Page Table (IA-32e) : 2-Mbyte (Huge page)

2017/1/4 6

2-Mbyte

- Offset : 21bit = 2MB

Huge Page Pros and Cons

2017/1/4 7

- TLBミスの減少(※)• ⼤容量のメモリを利⽤する際- ページエントリ解決時のメモリアクセス回数の減少- ページテーブルサイズの減少• ページテーブル全体がL2キャッ

シュに乗りやすい• 16GB表現に必要なpteサイズは

4Kページ → 32MB2Mページ → 64KB

- ページ確保により⼤きな連続したメモリ領域が必要- 未使⽤メモリ領域が増加- clear_page() / copy_page() 処理時間の増⼤• not cache friendly

Pros

Cons

(※) Huge Page⽤TLBのサイズも影響

TLB size

2017/1/4 8

L1 Data TLB4K page

L1 Data TLB2M pages

L2 TLB4K/2M pages

Core i7-3770K (Ivy Bridge)

4-way64 entries

4-way32 entries

4-way64 entries(4K only)

Core i7-4790K (Haswell)

4-way64 entries

4-way32 entries

8-way1024 entries

Core i7-6567U (Skylake)

4-way64 entries

4-way32 entries

6-way1536 entries

Haswell以降Huge Page⽤のL2 TLBが増加(調査⽅法 : cpuid)

Huge Pages in Linux

• CONFIG_HUGETLBFS=y

• huge page⽤領域を事前に確保• echo 256 | sudo tee -a /proc/sys/vm/nr_hugepages• huge page領域はswapされない

• huge pageの利⽤• mmap (…, MAP_HUGETLB, …)• shmget(…, SHM_HUGETLB, …)• hugetlbfs / libhugetlbfsを使う

• HUGETLB_MORECORE=yes LD_PRELOAD=libhugetlbfs.so ./a.out• textやdata sectionでhuge tableを利⽤する場合は適切にアラインする

• -Wl,hugetlbfs-align• HUGETLB_FORCE_ELFMAP

2017/1/4 9

LinuxでHuge Pageを利⽤する際の問題

• アプリケーションのコードの変更が基本的に必要

• swapできない

• Fair な割り当てが難しい

• 仮想化環境など，ワークロードが動的に変化する状況で使⽤するのが難しい• メモリを⼤量使⽤するアプリケーションを1つだけ動かす場合(e.g. DB

サーバ) には適している

2017/1/4 10

Transparent Huge Page (THP)

• huge pageをアプリケーション透過に利⽤• Linux 2.6.38~ (2011)• Anonymous Page Only

• /sys/kernel/mm/transparent_hugepage/enabled: THPの状態• always• madvice• never

• madvice(…,MADV_HUGEPAGE,…)madvice(…,MADV_NOHUGEPAGE,…)

• FairなHuge Pageの利⽤が期待される

2017/1/4 11

仮想化環境におけるTHPの効果 (1VM 1Task)

2017/1/4 12

Transparent Huge Page (THP)

2017/1/4 13

THP Problems

1. Page Fault Latency

2. Memory Bloat

3. Fragmentation

4. Unfairness

5. Memory Sharing

2017/1/4 14

1. Page Fault Latency

• THPを利⽤すると，ページフォルト時のレイテンシ（とその分散）が⼤きくなる

2017/1/4 15

THP Allocation Algorithm

• 戦略 : Greedy & Aggressive

2017/1/4 16

Get 2M Page

Page Fault

Memory CompactionTo get 2M Page Get 4K Page

Zero the pages Map the page to pte

y

n

y

n

(簡略化したPage Allocation⼿順)

2M Page = 512個の連続した4K Page

Latency増⼤の要因

• 2M Pageは0埋めに時間がかかる• 4K Page の512倍• 主要なレイテンシ増⼤の要因

• Memory Compaction の時間がかかることがある• Tail Latency増⼤の要因

2017/1/4 17

unfragmented fragmented

Base Page 3.6 us 8.1 us

Huge Page 378.0 us 8.1 us(ほぼ全てBase Pageを割り当て)

Page Fault Latency

105x

Asynchronous Promotion

• Linux には ⾮同期にHuge PageをPromotionする機能がある• khugepaged

• ◎ レイテンシ時間↓•❌ 割り当て速度が遅すぎる，CPU使⽤率↑

2017/1/4 18

2. Memory Bloat

• Huge Pageを利⽤すると，メモリ使⽤量が実際に必要な量よりも増⼤する• Greedy Allocationが⼤きく影響• メモリ使⽤量の⾒積もりが難しい

2017/1/4 19

3. Fragmentation

2017/1/4 20

Start memory compaction

4. Unfairness

• 実験• 4VM, 8GB Mem• 最初 fragmented 状態 (FMFI=0.85)1. VM0が全ての利⽤可能なHuge

Page(3GB)を確保2. VM1がメモリ割り当てを開始3. VM1のメモリ割り当て中にVM2,

VM3を起動4. VM0が終了し，3GBのHuge Page

を解放

• KVMのメモリ管理の問題

2017/1/4 21

VM0終了

5. Memory Sharing

• KVM: ゲストで共通のページを共有する機能がある

• ポリシー1 (KVMの今の実装)• Base Page単位で共有する• もし共有したいゲストのBase PageがホストのHuge Pageにある場合，

そのHuge PageをBase Pageに分割する

• ポリシー2 (huge page sharing)• Huge Page単位で共有する• Base Pageは共有しない• 著者が実装

2017/1/4 22

Memory Sharingとパフォーマンスの関係

2017/1/4 23

Ingens Memory Manager

• Goal• THP support that reduces latency, latency variance, bloat• Meaningful fairness guarantees• Reasonable tradeoffs b/w performance & memory savings

• Approach• あるHuge Pageの領域が，実際どのくらい利⽤されているかと，

どれくらいの頻度でHuge Page領域が利⽤されているかを計測し，それをメモリ管理に利⽤する

2017/1/4 24

2つのbitvectorによる統計情報の測定

• Util bitvector• Huge Pageの領域の中で，どのbase pageがアクセスされたかを保持• 512bit (4K × 512 = 2M)• プロセスごとに持つ (Radix treeで管理)• Page fault handlerがutil bitvectorを更新

• Access bitvector• ページアクセスのヒストリ• 定期的にpage tableのaccess bitを⾒てLinuxのpage metadataに

8bitで格納する (e.g. 00110111)• Ft: access frequency value

•

• weight(util bitvector) :util bitvectorの1の数の和• α : パラメータ

(実験では0.4 → Ft ≧ (3×bitvector size/4) = 6 のとき，frequently accessed)

2017/1/4 25

(access bitvectorの間違い?)

Page Fault Latencyの改善 : ⾮同期割り当て

• Page fault handlerがHugePageをpromoteするか判断

• Huge Pageをpromoteするとき，Promotion requestを投げる

• Promote-kth• Promotionを担当する

kernel thread• 必要であればcompaction

• Scan-kth• Access bitの更新をおこなう

kernel thread

2017/1/4 26

Bloatの改善: Utilization-based promotion

• Huge Page領域の中で⼀定量 (実験では90%)のBase Pageが利⽤されたら，Huge Pageにする• Promote-kth に promotion request• Huge Pageを利⽤した場合の最⼤メモリ使⽤量の⾒積もりが可能にな

る

2017/1/4 27

4K Page

2M Page

利⽤率25%

利⽤率100%

利⽤率100%

Bloatの改善: Utilization-based demotion

• プロセスがhuge page内のbase pageを解放するときがある

• redis• jemalloc()を利⽤• キーをdeleteするときにfree()を呼ぶ• freeの中で madvice(…, MADV_DONTNEED, …) する• その領域がHuge Pageに含まれる場合，LinuxはHuge PageをBase

pageに分解する→ 性能低下に繋がることがある

• Ingensは，utilizationが閾値を下回らない限りhuge pageを分解しない

2017/1/4 28

Fragmentationの改善: Batched Compaction

• Goal: FMFIを閾値以下に保つ (デフォルトは0.8)

• Compactionの課題• 先回りでcompactionをやりすぎると，CPU利⽤率が増加する• TLB invalidationが発⽣する

• Ingensのcompaction• 各compactionで対象とするメモリ量を100MB以下に制限• よくアクセスされる領域はcompactionしない

2017/1/4 29

Memory SharingとPerformanceのバランス

• KVM の memory sharing• base page単位で共有• 共有を優先• 共有する場所がHuge Pageならそれをbase pageに分解する

• Ingens• access frequency情報をpage sharingに利⽤する• 共有はKVMと同様base page単位• よくアクセスされるHuge pageは共有しない• 共有ページに書き込みがあると共有が外れるが，そのとき

utilizationをチェックして，閾値以上ならHuge Pageにする

2017/1/4 30

Fair Promotionのための指標

• 以下のshares-per-page ratio (ESXが利⽤)をメトリックに使う• Scan-kthがこの値を定期的に計算する

• S: プロセス(or VM)の huge page share priority• H: プロセスに割り当てられているhuge pageのバイト数• f: (huge page number) / (total page number), 0 ≦ f ≦ 1• τ: idleness penalty (0 ≦ τ ≦ 1)

2017/1/4 31

M⼤ → high priority of huge page promotion

Fair Promotion

• 以下の値が⼩さいとき，Fair な Allocationがおこなわれている

• Mi : プロセスiのPromotion metric• M = ΣMi

• Miが⼤きいプロセスから優先してhuge pageをpromotionする

2017/1/4 32

Implementation

• Linux 4.3 ベース

• ソース: https://github.com/ut-osa/ingens

• diff で7K LOC

2017/1/4 33

Implementation : Promote-kth

• Linuxのkhugepagedを置き換えて実装• 2つのpriority listを持つ• high : page fault handlerからのpromotion request (global)• normal : promote-kth が定期的にプロセスのアドレス空間をscanして

promoteすることにしたrequest (詳細は次のスライド)

• page fault あるいは 定期的なタイマで promote-kthがwake upし，優先度順にpromoteする

• page fault handlerがhuge pageを要求した領域が物理的に連続していないこともある• このときはページを連続する2Mの領域へコピーする

2017/1/4 34

Implementation : Promote-kthのScan

• Promote-kthは以下のように定期的なスキャン処理を実⾏する• promotion metric が fair-stateから最も離れているプロセスを選択• 16MB アドレス空間をスキャン• 10s sleep (i.e. 1.6MB/s)• 以上を繰り返す

• あるプロセスについてこの処理でpromotionされた領域が少ない場合は，120s スキャンの対象から外す• Promote-kth を占有することを防ぐため

2017/1/4 35

Implementation : Scan-kth

• Kernel4.3で追加された idle page tracking機能を使う• https://www.kernel.org/doc/Documentation/vm/idle_page_tracking.tx

t• 各物理ページにidle flagを追加• HWがaccess bitを⽴てたとき，idle flagをクリア• APでidle flagの状態を取得 / クリア

• x86ではaccess bitをクリアするとTLB invalidationが発⽣する• 定期的なスキャンは性能を下げる可能性

• ingensでは，pageが• 頻繁にアクセスされていない → クリア• 頻繁にアクセスされている → 20%の確率でクリア

• このとき，29%のオーバーヘッドが8%に減少 (worst-case, 平均は1%のoverhead)

2017/1/4 36

Evaluation: Ingens Overhead

2017/1/4 37

slowdownの原因- Linuxと⽐べてaggressiveにhuge pageを割り当てない．

ingensが割り当てるまで遅いbase pageを使う- utilization の計算memory-intensiveでないworkload(PRASEC 3.0)では平均0.8%

Evaluation: Ingens Overhead

2017/1/4 38

- Access bit trackingで10%程度のCPU utilization

Evaluation: Utilization-based promotion

2017/1/4 39

Ingensの性能向上の要因 : page fault latencyが⼩さくなった(Linux: memory compactionに時間を費やしている)メモリがunfragmentedなとき，ingensはLinuxと⽐べて，13.4% throuput ↓, 18.1% latency ↑

Evaluation: Memory bloating

2017/1/4 40- Ingens-70% でもnohugeの場合とほぼ同じメモリ使⽤- 99.9th latency のみ遅くなっている (ただしnohugeよりは良い)

Evaluation: Fair huge page promotion

2017/1/4 41

IngensはFairな割り当てを実現

Canneal-1のアドレス空間のスキャンが完了,Canneal-2のアドレス空間のスキャンを開始

Evaluation: Memory saving & Performance

2017/1/4 42

Future work

• anonymous page以外の対応• 現在Linuxのhuge pageがanonymous pageのみ

• page cacheはI/O trafficを増⼤させる• Free BSDは read-only page cacheをサポート

• NUMA consideration• 現在ingensはlinuxのNUMA heuristicsをそのまま利⽤

2017/1/4 43

FreeBSD での Transparent Huge Page

• Reservation-based huge page allocation• Page fault handlerは2MB の連続領域を割り当てるが，

その領域全てがアクセスされるまでそれをHuge Pageにしない• Less Memory Bloat

• No Memory Compaction

• (Windows, macOS : No Transparent Huge Page)

2017/1/4 44

SVM Canneal Redis

FreeBSD 1.28 1.13 1.02

Linux 1.30 1.21 1.15

Ingens 1.29 1.19 1.15

まとめ

• LinuxのHuge page allocationはpoolingベース• fairな割り当てが難しい，コード修正が必要

• Transparent Huge Page (THP)はアプリケーション透過にhuge pageを利⽤する

• ingensは以下のTHPの問題を改善• page fault latency• memory bloat• fragmentation• unfairness• memory sharing

2017/1/4 45

感想

• この論⽂の良い点• 現在のTHP実装について5つ問題を指摘し，それぞれについて解決策

を提案，実装して評価.

• 疑問点とか• 特定のVMに優先して割り当てたいとき，現在のメトリックでうまく

いくのか (→ Sの値を変えればいいのか)• jemallocなどをhuge page awareにして性能改善できないのか

• 誰かやってそう• 最近のLinuxだとTHP周りはどうなっているのか

• ingensの名前の意味は..?

2017/1/4 46

Reference

• https://www.usenix.org/conference/osdi16/technical-sessions/presentation/kwon

• https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

• https://www.kernel.org/doc/Documentation/vm/transhuge.txt

• http://www.linux-kvm.org/images/9/9e/2010-forum-thp.pdf

• https://lwn.net/Articles/374424/

• https://lwn.net/Articles/423584/

2017/1/4 47