Tạo một luồng tốn 42us, tạo một tiến trình 96us — nhanh hơn ~2 lần, không phải 100 lần như folklore. Và 1000 luồng làm VmSize +8GB nhưng RAM thật chỉ +8MB: 8MB mỗi luồng chỉ là địa chỉ ảo đặt trước cho ngăn xếp, không phải RAM. Đo thật.
Ghim lõi giữ cache nóng, nhanh hơn 32% khi working-set vừa cache (64KB) — nhưng 0% khi vượt cache (4MB) vì lúc đó tải là memory-bound. Và cái đuôi trễ nhọn trong máy ảo là nhiễu tầng ảo hóa, không phải do di trú lõi — chỉ lộ ra khi lặp đủ nhiều. Ghim đúng chỗ thì đáng, ghim vì tin đồn thì vô ích.
write() không đưa dữ liệu xuống đĩa ngay. Tôi ghi 300MB không fsync và nhìn Dirty trong /proc/meminfo: nó ghim nguyên 300MB suốt 30 giây rồi mới về 0. Cửa sổ 30 giây đó — nếu mất điện là bay sạch — chính là lý do phải fsync. Đo thật, kèm một cái bẫy quan sát.
Mỗi lượt một tiến trình chạy ~3 ms rồi bị đẩy ra, và con số đó cố định dù 2 hay 8 tiến trình tranh CPU. Nhưng lần đầu tôi không thấy chia lượt gì cả (quên ghim CPU), và thứ tôi đang đo hóa ra là EEVDF chứ không phải CFS như tên bài. Đo thật hai cú vấp về bộ lập lịch.
fork() không sao chép dữ liệu nhờ copy-on-write (fork 1GB 1,6ms so với memcpy 490ms, nhanh hơn 310 lần), nhưng nó vẫn tốn O(bộ nhớ) vì phải sao chép bảng trang ngay: 33us ở 1MB lên 1613us ở 1GB. Và trên đường đo, gcc -O2 lặng lẽ xóa mất phép memcpy cho ra 0 giây. Đo thật.
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.