execve thay ảnh tiến trình tại chỗ: cùng PID, chương trình khác, và nạp lười nên exec file 64MB (354µs) nhanh ngang file 70KB (392µs). Tôi bọc nó bằng printf trước và sau để đo — cả hai đều mất, vì execve vứt bộ đệm chưa xả và không trở về khi thành công. Phải fflush trước và đo từ tiến trình cha.
Chạm 64MB bộ nhớ mới tôi tưởng gây 16.384 lỗi trang; getrusage ra 32 — vì trang lớn trong suốt (THP) 2MB, một lỗi lo trọn 2MB. Tắt THP ra đúng 16.384 (lệch 512 lần). Và đọc file đã nằm trong cache gần như không gây lỗi trang nặng nào. Kích thước trang và page cache là biến ẩn — phải đo, đừng nhẩm.
mmap 4GB làm VSZ nhảy lên 4098MB nhưng RSS đứng yên ở 1MB — tôi suýt nhìn nhầm cột và phóng đại mức dùng RAM 4000 lần. RSS mới là RAM thật, VSZ chỉ là địa chỉ ảo đã đặt chỗ. Và mmap 64GB trên máy 8GB vẫn thành công. 'Bộ nhớ' không phải một con số — hỏi rõ cột nào trước khi tin.
malloc không phải syscall: 2000 khối nhỏ chỉ sinh 4 lần brk (gom lô ở user space), mỗi malloc+free 64B tốn 9,4 ns; khối lớn 256KB+ mới mmap riêng. Nhưng khi tôi đo malloc 1MB bằng bản -O2, strace trống trơn — optimizer đã xóa mất cặp malloc/free không dùng. Mức -O là biến ẩn cả trong phép đo strace.
Huge page 2MB làm truy cập ngẫu nhiên trên 512MB nhanh ~30% (28,83 xuống 20,33 ns/bước) nhờ ít TLB miss. Nhưng tôi đo bằng truy cập tuần tự trước, thấy hai bên bằng nhau (1,18 vs 1,31 ns), suýt kết huge page vô dụng — vì tuần tự thì prefetch che hết TLB. Mẫu truy cập là biến ẩn quyết định.
Page cache giữ file trong RAM để đọc lại tức thì (Cached 5,5GB, đọc 256MB ở ~36GB/s, 0 lỗi trang nặng). Nhưng trong container tôi không tạo nổi lần đọc 'nguội': overlayfs không có đĩa chậm thật bên dưới, FUSE thì bỏ qua page cache khách nên luôn chậm. Đo I/O trong container là đo tầng ảo hóa, không phải đĩa.