Thấy container dùng 255 trên 256 MB, tôi hoảng 'sắp OOM'. Nhưng nếu chỗ đầy đó là page cache thì container khỏe re, oom_kill=0; nếu là anon thì exit 137, bị giết ngay. Con số 'đang dùng bao nhiêu' đứng một mình gần như vô dụng — chỉ thành phần mới nói. Đo thật.
Truy cập ngẫu nhiên trên 1 GB: trang 4KB mất 138 ns/lần, trang lớn 2MB chỉ 114 ns — phần chênh là chi phí lỗi TLB. Nhưng lần đầu hai bản nhanh y hệt, vì THP=always khiến cái 'nền 4KB' của tôi thực ra là trang lớn. Xác minh điều kiện, đừng suy từ ý định. Đo thật.
Chuyển 1 GB giữa hai tiến trình: pipe 3,1 GB/s, bộ nhớ chia sẻ ring nhiều đệm 9,8 GB/s (~3×). Nhưng shm một đệm lại chậm hơn pipe, và bản bỏ đồng bộ cho 15 GB/s với checksum 'KHỚP' đã suýt lừa tôi viết kết luận sai — vì đo nhầm đại lượng và một phép kiểm vô dụng. Đo thật.
Khóa mutex khi không ai tranh chỉ tốn 5,4 ns, thuần userspace, không syscall. Tôi tưởng tranh chấp sẽ đắt gấp trăm lần vì syscall futex() — nhưng đo ra chỉ chậm ~4 lần, và strace cho thấy 99,86% số lần khóa vẫn không vào kernel. Cái đắt hóa ra không phải syscall. Đo thật.
Chạm 200MB anon chỉ sinh 102 lỗi trang, không phải 51200 — vì trang lớn THP. Và đọc file lạnh từ đĩa chỉ đếm 1 major fault dù chậm gấp 27 lần cache — vì readahead. Đo thật bằng getrusage.
write() một khối 512 byte tốn 0,39µs; thêm fdatasync thành 518µs — gấp 1312 lần trên overlayfs, nhưng chỉ 4,2 lần trên FUSE. Tỉ lệ khác nhau là vì write baseline khác nhau, không phải fsync bất thường. Và write() trả về thành công KHÔNG bảo đảm dữ liệu đã bền — chỉ fsync mới.