mmap & copy-on-write — chia sẻ trang thông minh

TL;DR: mmap ánh xạ một file (hoặc vùng ẩn danh) vào không gian địa chỉ ảo của tiến trình — bạn đọc/ghi file như thao tác con trỏ, OS tự nạp trang theo demand paging. Copy-on-write (COW) là kỹ thuật chia sẻ: khi fork(), cha và con dùng chung trang vật lý, đánh dấu read-only. Khi một bên ghi, page fault kích OS copy riêng trang đó. Nhờ vậy fork tiến trình 4 GB trả về gần tức thì — chỉ trả giá thật cho trang thực sự bị ghi sau đó. Hai cơ chế này là nền tảng của shared library, zero-copy I/O, và fork-based server.

fork() một tiến trình đang dùng 4 GB bộ nhớ. Bạn có thể nghĩ: OS phải copy 4 GB trước khi con chạy — chắc mất vài giây? Thực tế lời gọi trả về dưới 1 millisecond, và nếu con gọi exec() ngay (mẫu fork-exec cổ điển), hầu như không có trang nào được copy thật sự. Còn libc — thư viện C dùng chung của trăm tiến trình — chỉ tồn tại một bản vật lý trong RAM dù mỗi tiến trình thấy nó tại địa chỉ ảo của riêng mình.

Cả hai hiện tượng đó dựa trên cùng một nguyên tắc: chia sẻ trang vật lý qua lớp gián tiếp của bộ nhớ ảo, kết hợp với page fault làm cơ chế kích hoạt copy hoặc nạp theo nhu cầu.

1. Analogy — phòng họp chia sẻ và tài liệu photocopy khi cần

Hình dung một văn phòng với một phòng họp (bộ nhớ vật lý). Thay vì photo toàn bộ bộ tài liệu cho mỗi người trước buổi họp, mọi người đọc từ bản gốc chung. Khi ai đó muốn ghi chú riêng lên tài liệu, họ mới photo đúng trang đó và ghi vào bản riêng — người còn lại vẫn dùng bản gốc.

2. mmap — ánh xạ file vào không gian địa chỉ

mmap (memory-mapped file) là syscall cho phép ánh xạ nội dung file (hoặc vùng ẩn danh) vào một vùng địa chỉ ảo của tiến trình. Sau khi map, truy cập địa chỉ ảo đó tương đương đọc/ghi file — không cần read()/write() thủ công.

int fd = open("data.bin", O_RDONLY);
// Map file vao khong gian dia chi ao, chi doc
void *map = mmap(NULL, file_size, PROT_READ, MAP_PRIVATE, fd, 0);
// Gio co the truy cap file nhu mang:
uint32_t val = ((uint32_t*)map)[index];
// Khi xong:
munmap(map, file_size);
close(fd);

Cơ chế bên dưới

Sau mmap, OS tạo một VMA (Virtual Memory Area) trong không gian địa chỉ tiến trình — dải địa chỉ ảo hợp lệ trỏ tới file. Nhưng chưa có trang nào được nạp vào RAM — PTE vẫn absent.

Khi tiến trình đọc byte đầu tiên trong vùng map:

1. MMU thấy PTE absent → page fault.
2. OS handler nhận fault, tra VMA, biết đây là fault trong vùng mmap'd file.
3. OS đọc trang tương ứng từ file vào một khung vật lý (major fault).
4. PTE cập nhật present = 1, trỏ vào khung.
5. CPU retry — tiến trình đọc được dữ liệu.

Các trang kế tiếp nạp theo demand tương tự — chỉ khi thật sự truy cập.

Ứng dụng thực tế của mmap

Shared library (.so/.dylib): khi nhiều tiến trình load libc, OS map cùng trang vật lý của code libc vào không gian địa chỉ ảo của mỗi tiến trình. 200 tiến trình dùng libc → chỉ 1 bản vật lý trong RAM. Nối với bài 01 — chia sẻ libc.

Executable loading: khi exec() chạy chương trình, OS không copy binary vào heap — nó mmap các segment (text, rodata, data) từ ELF file. Code chương trình được nạp theo demand paging khi CPU thực thi từng hàm lần đầu.

File lớn hơn RAM: bạn có thể mmap file 100 GB trên máy 16 GB RAM vì chỉ vùng đang truy cập mới cần trong RAM.

Anonymous mmap: malloc của nhiều allocator thực ra gọi mmap(MAP_ANONYMOUS) cho allocation lớn thay vì sbrk — linh hoạt hơn để trả bộ nhớ về OS sau khi free.

MAP_SHARED vs MAP_PRIVATE

3. Copy-on-write — fork rẻ nhờ chia sẻ trang

fork() trước COW

Trước khi COW phổ biến, fork() copy toàn bộ bộ nhớ tiến trình cha sang con — tốn thời gian và RAM tỉ lệ thuận với kích thước tiến trình. Server Apache cũ dùng fork mỗi request: tiến trình 100 MB → fork 100 MB → chậm.

Cơ chế COW

Với COW, khi fork():

1. OS không copy bất kỳ trang dữ liệu nào.
2. OS tạo một page table mới cho tiến trình con, nhưng mọi PTE trỏ vào cùng khung vật lý với cha.
3. Cả hai page table đều đánh dấu các trang đó là read-only (write-protected).
4. fork() trả về gần tức thì — chỉ mất thời gian copy page table, không phải dữ liệu.

flowchart TD
  subgraph Before["Truoc khi ghi"]
    FA["Tien trinh Cha<br/>PTE: khung #42 read-only"]
    CA["Tien trinh Con<br/>PTE: khung #42 read-only"]
    FA -->|"chia se"| P42["Khung vat ly #42<br/>[data: hello]"]
    CA -->|"chia se"| P42
  end
  subgraph After["Sau khi Con ghi vao trang"]
    FB["Tien trinh Cha<br/>PTE: khung #42 read-only"]
    CB["Tien trinh Con<br/>PTE: khung #99 read-write"]
    FB --> P42b["Khung #42<br/>[data: hello]"]
    CB --> P99["Khung #99 (ban sao)<br/>[data: world]"]
  end
  Before -->|"Con ghi -> page fault -> OS copy"| After

Khi tiến trình con (hoặc cha) ghi vào trang shared:

1. CPU phát write page fault (trang đánh dấu read-only).
2. OS COW handler:
   • Cấp một khung vật lý mới.
   • Copy nội dung khung gốc vào khung mới.
   • Cập nhật PTE của bên ghi trỏ sang khung mới, đặt lại read-write.
   • Nếu chỉ còn 1 tiến trình reference khung gốc, đặt lại read-write cho khung gốc luôn.
3. CPU retry lệnh ghi — thành công trên bản sao riêng.

Chi phí thực sự của fork: chỉ trả giá cho số trang thực sự bị ghi sau fork. Nếu con gọi exec() ngay (pattern fork-exec), hầu như không có trang nào bị copy.

Minh hoạ: fork với array lớn

static int data[1000000];  // ~4 MB -- static (BSS), tranh tran stack
memset(data, 0, sizeof(data));

pid_t pid = fork();
if (pid == 0) {
    // Con: chi doc data, khong ghi -> khong copy trang nao
    printf("sum = %d\n", sum(data, 1000000));
    exit(0);
}
// Cha: tiep tuc chinh sua data -> moi trang duoc sua moi duoc copy
data[0] = 42;  // -> COW: copy trang chua data[0]

Sau fork(), cả 4 MB chia sẻ. Con chỉ đọc → 0 byte copy. Cha ghi 1 phần tử → chỉ trang chứa phần tử đó (~4 KB) bị copy.

4. Pitfall tổng hợp

❌ Nhầm 1: MAP_SHARED khi cần isolation. Với MAP_SHARED, ghi của tiến trình này phản ánh lên file và tới tiến trình khác đang map cùng file. Nếu muốn đọc file mà không sửa hoặc không ảnh hưởng tiến trình khác, dùng MAP_PRIVATE.

❌ Nhầm 2: mmap luôn nhanh hơn read/write. mmap tiết kiệm một lần copy từ kernel buffer sang user buffer. Nhưng với access pattern ngẫu nhiên, mỗi page miss là một major fault; với file nhỏ, overhead setup VMA có thể vượt lợi ích. Benchmark trước khi quyết định.

❌ Nhầm 3: fork + ghi nhiều trang = COW overhead thật. Nếu sau fork tiến trình con sửa phần lớn bộ nhớ (ví dụ worker Redis sau BGSAVE), COW copy sẽ tốn CPU và bộ nhớ tương đương copy thủ công. Redis có thể dùng gần gấp đôi RAM trong lúc fork đang chạy vì copy-on-write liên tục.

❌ Nhầm 4: munmap không cần thiết. Bỏ munmap trước khi exit thì OS dọn tự động, nhưng trong tiến trình sống lâu, quên munmap rò địa chỉ ảo (VMA leak) — đặc biệt nguy hiểm trên 32-bit.

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

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

• Bài 01 — Vì sao cần bộ nhớ ảo: shared library (libc) chia sẻ trang là ví dụ kinh điển của mmap — một bản vật lý dùng cho trăm tiến trình.
• Bài 04 — Page fault & swap: page fault là cơ chế kích hoạt cả mmap (nạp trang từ file) lẫn COW (copy trang khi bị ghi). Không hiểu fault thì không hiểu tại sao mmap và COW hoạt động.
• Module 1 — Heap & cấp phát động: malloc lớn thực chất gọi mmap(MAP_ANONYMOUS) bên dưới; hiểu mmap giải thích tại sao heap có thể trả bộ nhớ về OS khi free (thứ sbrk không làm được).

7. Tóm tắt

• mmap ánh xạ file (hoặc vùng ẩn danh) vào không gian địa chỉ ảo. OS nạp trang theo demand paging khi chạm lần đầu. File lớn hơn RAM vẫn map được vì chỉ phần đang truy cập cần trong RAM.
• MAP_SHARED chia sẻ ghi với file và tiến trình khác; MAP_PRIVATE dùng COW — ghi tạo bản sao riêng, không ảnh hưởng file.
• Copy-on-write (COW): khi fork(), cha và con chia sẻ cùng trang vật lý (đánh dấu read-only). Khi một bên ghi → write page fault → OS copy trang đó sang khung mới cho bên ghi. fork trả về tức thì vì chỉ copy page table, không copy dữ liệu.
• COW overhead thật phát sinh chỉ cho trang thực sự bị ghi sau fork. fork-exec (fork rồi exec ngay) gần như không copy trang nào.
• Shared library (libc) chia sẻ trang vật lý qua mmap — hàng trăm tiến trình dùng chung một bản RAM nhờ lớp gián tiếp của bộ nhớ ảo.

8. Tự kiểm tra

Bài tiếp theo: Tổng kết module — Bộ nhớ ảo