Tưởng getpid() được glibc cache nên gần như free, và hàm nào trông như syscall cũng vào kernel? Tôi đo: một syscall thật ~103ns (450× một phép tính), getpid glibc không còn cache nên vẫn 100ns, còn clock_gettime qua vDSO chỉ 12,7ns vì chạy hẳn trong user mode. 'Trông như syscall' không quyết định giá.
Tưởng fork đắt vì phải sao chép cả bộ nhớ? Tôi đo: Copy-on-Write nên fork KHÔNG chép dữ liệu — chỉ 74µs, 1,6 lần một luồng. Nhưng CoW không làm fork miễn phí theo kích thước: fork sau khi cấp 256MB chậm 1,86 lần vì vẫn phải nhân đôi bảng trang. CoW cắt chép dữ liệu, không cắt chép bảng trang.
Tưởng sau fork con đọc/ghi đều như thường, và Copy-on-Write gần như miễn phí? Tôi đo: đọc trang rẻ (15,6ns) nhưng lần ghi đầu vào mỗi trang tốn 909ns — 96 lần lần ghi sau — vì mỗi trang phải chịu một CoW fault (bẫy, cấp trang, chép 4KB). CoW không free, chỉ hoãn cái giá chép.
Tưởng exec chỉ là nhảy vào chương trình mới nên tức thì? Tôi đo: execve tốn 45,6µs cho binary tĩnh (nạp ELF, ánh xạ segment), và 73,5µs cho binary động — chậm 1,61 lần dù file nhỏ hơn 12 lần, vì trình liên kết ld.so phải phân giải symbol trước main. Nhỏ trên đĩa không bằng nhanh lúc chạy.
Tưởng chuyển ngữ cảnh giữa hai tiến trình đắt hơn nhiều so với giữa hai luồng vì phải flush TLB? Tôi đo: chỉ 1,09 lần (579ns vs 532ns) — CPU hiện đại gắn ASID/PCID nên đổi bảng trang không cần flush. Nhưng đó chỉ là chi phí trực tiếp; khác biệt thật ngoài đời là gián tiếp (cache nguội).
Tưởng mmap/malloc xong là có bộ nhớ dùng ngay, và đo chi phí fault chỉ cần chạm trang rồi chia số trang? Tôi đo: một minor fault ~368ns, nhưng rusage lộ ra chỉ 364 fault cho 30.000 trang vì huge page gom 512 trang mỗi fault — chia đều thành 58ns là sai gần 6 lần. Phải đếm số fault thật.