MMU & TLB — dịch địa chỉ mà không chậm

TL;DR: Mỗi lần chương trình đọc hay ghi bộ nhớ, địa chỉ ảo phải được dịch sang địa chỉ vật lý. Việc đó do MMU (Memory Management Unit) — một phần cứng tích hợp trong CPU — thực hiện bằng cách walk qua page table. Vấn đề: page table nằm trong RAM (~100 ns mỗi lần truy cập), nên mỗi truy cập bộ nhớ lại tốn thêm vài lần truy cập RAM để dịch — tới ~5 lần chi phí với page table 4 cấp. TLB (Translation Lookaside Buffer) là một cache cực nhỏ, cực nhanh nằm ngay trong MMU, lưu các bản dịch VPN→PFN gần đây. TLB hit dịch địa chỉ chỉ tốn ~1 chu kỳ; TLB miss mới phải walk page table. Nhờ locality (bài module 2), TLB hit rate thường vượt 99% — dịch địa chỉ gần như miễn phí trong thực tế.

Bạn chạy một vòng lặp duyệt mảng 1 triệu phần tử. Mỗi phần tử là một truy cập bộ nhớ — tức 1 triệu lần dịch địa chỉ. Nếu mỗi lần phải walk page table 4 cấp xuống RAM (~400 ns theo ước lượng lý thuyết — con số thực tế thấp hơn nhờ page walk cache, xem mục Đào sâu), vòng lặp mất thêm hàng trăm ms chỉ cho dịch địa chỉ. Nhưng thực tế vòng lặp không chậm đến vậy.

Câu trả lời là TLB. Bài này giải thích MMU làm gì, TLB hoạt động thế nào, vì sao nó hiệu quả, và cái giá phải trả khi TLB bị flush.

1. Analogy — sổ tay tra nhanh của lễ tân

Lễ tân khách sạn (bài 01) có bảng tra phòng lớn trong kho — nhưng kho nằm ở tầng hầm, mỗi lần xuống mất 2 phút. Nếu cứ mỗi yêu cầu đặt phòng lại phải xuống hầm tra bảng, khách xếp hàng dài.

Lễ tân khôn ngoan giữ một sổ tay nhỏ trên bàn: ghi lại 50–100 cặp "số phòng ảo → số phòng thật" của những khách hay gặp nhất gần đây. Khi khách hỏi, tra sổ tay trước — tìm thấy ngay (TLB hit); không có mới xuống hầm (TLB miss), rồi cập nhật sổ tay cho lần sau.

2. MMU — phần cứng dịch mọi địa chỉ

MMU (Memory Management Unit) là phần cứng tích hợp trong CPU, đứng giữa CPU core và bus bộ nhớ. Mọi địa chỉ CPU phát ra — kể cả địa chỉ để nạp lệnh — đều đi qua MMU trước khi ra bus.

MMU dịch địa chỉ bằng cách walk page table: với page 4 cấp (x86-64), nó đọc lần lượt PML4 → PDPT → PD → PT, mỗi cấp dùng 9 bit của VPN làm chỉ số. Kết quả là PFN trong PTE cấp cuối, ghép với offset ra địa chỉ vật lý.

flowchart LR
  CPU["CPU<br/>(phat VA)"] --> TLB{"TLB<br/>hit?"}
  TLB -->|hit| PA["Dia chi vat ly (PA)"]
  TLB -->|miss| Walk["Page table walk<br/>(MMU doc RAM)"]
  Walk -->|cap nhat TLB| TLB
  Walk --> PA
  PA --> Cache["L1/L2/L3 Cache<br/>+ RAM"]

Phân biệt OS và MMU: page table là cấu trúc dữ liệu do OS tạo và cập nhật (khi cấp phát vùng nhớ, khi swap trang, khi context switch). MMU chỉ đọc page table theo địa chỉ gốc được lưu trong thanh ghi CR3 (x86) — nó là phần cứng, không có logic OS. Khi OS muốn đổi page table (context switch), nó ghi địa chỉ page table mới vào CR3.

3. Chi phí nếu không có TLB

Để thấy TLB quan trọng thế nào, hãy tính chi phí không có nó. Với x86-64 dùng 4-level page table, mỗi lần dịch địa chỉ cần 4 lần đọc RAM:

Khong co TLB — chi phi moi truy cap bo nho:
  1 lan doc PML4       ~100 ns  (RAM)
  1 lan doc PDPT       ~100 ns
  1 lan doc PD         ~100 ns
  1 lan doc PT         ~100 ns
  1 lan doc du lieu    ~100 ns  (truy cap that su)
  -----------------------------------------------
  Tong                 ~500 ns  (gap 5x chi phi goc)

Vòng lặp 1 triệu phần tử: nếu mỗi truy cập tốn 500 ns → 500 ms chỉ cho bộ nhớ. Thực tế với TLB hit rate 99%:

Co TLB (hit rate 99%):
  990.000 lan TLB hit: ~1 chu ky x 990.000    ~1 ms
   10.000 lan TLB miss: ~400 ns x 10.000      ~4 ms
  -----------------------------------------------
  Tong                                        ~5 ms

Khác biệt ~100 lần. TLB biến việc dịch địa chỉ từ nút cổ chai thành chi phí không đáng kể.

4. Vì sao TLB hit rate cao — locality (lại!)

TLB chỉ lưu vài chục tới vài nghìn entry (L1 TLB thường 64–128 entry, L2 TLB 512–2048). Tại sao lại đủ?

Vì locality (đã gặp ở module 2): chương trình không nhảy khắp không gian địa chỉ — nó tập trung vào một số trang trong khoảng thời gian dài (temporal locality) và duyệt các trang liền nhau (spatial locality). Code ở một vài trang; dữ liệu hot (mảng đang duyệt, stack frame hiện tại) ở một vài trang.

Vi du: duyet mang 64 MB (page 4 KB = 16.384 trang)
  - Duyet tuan tu: tai mot thoi diem, chi can ~2-4 trang hien hanh
  - Moi trang phuc vu ~1.024 phan tu int
  - TLB 64 entry la du cho toan bo working set cua vong lap

Trang nào đã dịch gần đây sẽ còn trong TLB cho các truy cập tiếp theo trong cùng trang đó. Một cache line 64 byte nằm gọn trong một trang → cả block spatial locality được phục vụ từ một TLB entry.

5. Multi-level page table — vì sao cần

Bài 02 đặt vấn đề: page table phẳng cho 48-bit address space cần 2^36 entry × 8 byte = 512 GB mỗi tiến trình — không khả thi.

Multi-level page table giải quyết bằng cách phân cấp: thay vì một mảng khổng lồ, dùng một cây thưa. x86-64 dùng 4 cấp, mỗi cấp dùng 9 bit của VPN:

Dia chi ao 48-bit x86-64:

  [9 bit PML4][9 bit PDPT][9 bit PD][9 bit PT][12 bit offset]
      ^cấp 1      ^cấp 2     ^cấp 3   ^cấp 4

  Moi cap: bang 512 entry x 8 byte = 4 KB (vua 1 trang!)
  Chi cap phat bang cho phan cay thuc su duoc dung.

Lợi ích then chốt: tiến trình thưa (chỉ dùng vài vùng nhỏ trong không gian ảo khổng lồ) chỉ cần cấp phát các nhánh cây thật sự ánh xạ — phần còn lại của cây không tồn tại. Chi phí thực: bộ nhớ cho page table tỉ lệ với số trang thật sự được ánh xạ (O(số trang)) thay vì cố định 512 GB; còn mỗi lần dịch chỉ tốn số bước bằng số cấp = 4 (hằng số), không phụ thuộc kích thước không gian địa chỉ.

Nhược điểm: mỗi TLB miss giờ cần 4 lần đọc RAM (4 cấp) thay vì 1 — đó là lý do TLB hit rate cao hơn lại càng quan trọng.

6. Context switch và TLB flush

Khi OS switch từ tiến trình A sang B, page table thay đổi (OS ghi CR3 mới). Tất cả entry trong TLB hiện tại đều thuộc về A — chúng không còn hợp lệ cho B.

Giải pháp đơn giản: flush TLB. Ghi CR3 trên x86 tự động flush các entry không phải global (kernel mapping được đánh dấu Global qua CR4.PGE vẫn được giữ — để khỏi nạp lại sau mỗi switch). Chi phí: entry của tiến trình cũ bị xoá, các truy cập đầu tiên sau switch đều là TLB miss → page walk.

Chi phi context switch co TLB flush:
  Sau switch, N truy cap dau tien:
    N x TLB miss x 400 ns (4-level walk)
  N phu thuoc working set size va duoc fill dan.
  He thong switch nhieu (scheduler goi nhieu) -> overhead dang ke.

Giải pháp tối ưu: ASID/PCID. Mỗi TLB entry được gắn thêm một Address Space ID (ASID) (hoặc PCID trên x86). MMU chỉ chấp nhận hit khi ASID của entry khớp với ASID hiện tại. Khi switch A → B, OS chỉ đổi ASID hiện tại — TLB entry của A vẫn còn đó nhưng bị bỏ qua. Khi quay lại A, ASID khớp → entry A vẫn dùng được, không cần refill. Chi phí switch giảm đáng kể.

7. Pitfall tổng hợp

❌ Nhầm 1: Nghĩ TLB là cache dữ liệu. TLB chỉ lưu bản dịch địa chỉ (VPN→PFN), không lưu dữ liệu thật. TLB hit nghĩa là "đã biết địa chỉ vật lý", không phải "dữ liệu đã trong cache".

❌ Nhầm 2: Tưởng TLB flush chỉ xảy ra khi context switch. TLB entry cũng bị vô hiệu khi OS thay đổi PTE (unmap trang, thay đổi quyền). OS phải chủ động flush entry liên quan — trên đa nhân, cần TLB shootdown: gửi IPI (inter-processor interrupt) tới mọi core để flush entry đó trên toàn hệ thống (xem Đào sâu).

❌ Nhầm 3: Bỏ qua huge pages để tối ưu TLB. Một TLB entry cho trang 4 KB phủ 4 KB; một entry cho huge page 2 MB phủ 512 lần nhiều hơn. Với working set lớn hơn TLB coverage (nhiều trang nhỏ → nhiều miss), chuyển sang huge pages có thể giảm TLB miss rate đáng kể — đặc biệt với database, JVM heap lớn.

8. Đào sâu (tuỳ chọn)

9. Liên hệ các bài khác

• Bài 02 — Paging & page table: cấu trúc page table mà MMU walk qua; VPN/PFN/offset MMU dùng để dịch.
• Bài 04 — Page fault & swap: khi MMU gặp PTE với present = 0, nó raise page fault exception — OS xử lý tiếp.
• Module 2 — Vì sao có cache & độ trễ: thang độ trễ L1/L2/RAM dùng để so sánh chi phí TLB hit (~1 chu kỳ) vs TLB miss (walk qua RAM ~100 ns mỗi cấp).

10. Tóm tắt

• MMU là phần cứng trong CPU dịch mọi địa chỉ ảo sang vật lý bằng cách walk page table. OS dựng và cập nhật page table; MMU chỉ đọc nó.
• Không có TLB, mỗi truy cập bộ nhớ cần thêm 4 lần đọc RAM (4-level page walk) — tốn ~500 ns thay vì ~100 ns (ước lượng lý thuyết; thực tế thấp hơn nhờ page walk cache — xem mục 8).
• TLB là cache nhỏ (~64–2048 entry) ngay trong MMU, lưu bản dịch VPN→PFN gần đây. TLB hit ~1 chu kỳ; TLB miss → page walk.
• TLB hiệu quả nhờ locality: chương trình tập trung vào ít trang tại một thời điểm → hit rate thường vượt 99%.
• Context switch đổi CR3 → flush TLB (hoặc dùng ASID/PCID để tránh flush). Chi phí flush: mọi truy cập đầu tiên sau switch đều miss → page walk.
• Huge pages (2 MB/1 GB) giảm số TLB entry cần thiết, giúp với working set lớn hơn TLB coverage.

11. Tự kiểm tra

Bài tiếp theo: Page fault & swap