/proc không phải file trên đĩa — nhân sinh nội dung tại chỗ mỗi lần đọc (nên stat báo 0 byte). Tôi đọc /proc/self/stat để xem CPU mình tăng, mãi được 0/0: self là kẻ đang đọc, không phải chương trình tôi nghĩ. Bốn trạng thái R/S/D/Z và cách chẩn đoán không cần cài gì.
Đọc tuần tự 6701 MB/s, ngẫu nhiên 295 MB/s. Tôi định giải thích bằng 'seek' — rồi nhớ ra đây là SSD, không có đầu đọc để seek. Tách biến: đọc tuần tự y hệt mà TẮT readahead thì sụp còn 134 MB/s, chậm 50 lần. Thủ phạm thật là readahead, không phải seek. Đo thật.
fork một tiến trình 512MB chỉ tốn 28µs — nó không sao chép dữ liệu, chỉ chép bảng trang (nhanh hơn nghìn lần). Nhưng chi phí sao chép không mất, nó bị hoãn: ghi vào 64MB heap chung sau fork tốn 20,2ms với 16.419 COW fault, chậm ~200 lần ghi thường. Khi cái gì 'gần như miễn phí', hỏi tiếp chi phí đi đâu.
Đo SCHED_FIFO so tiến trình thường ra 50:50 sạch sẽ — nhưng mã trả về rtok=0 tố cáo lệnh đặt lịch RT đã thất bại, tôi đang đo hai tiến trình thường. Cấp quyền RT: FIFO đè còn 95:5 — và cái 5% không phải real-time lịch sự mà là van an toàn của nhân chặn ở 95% để bạn không treo máy.
Một syscall (getpid) tốn ~120 ns, gấp ~55 lần một lời gọi hàm (~2 ns) — vì phải vượt vào kernel. Tôi tưởng glibc cache pid nên getpid rẻ; strace chứng minh nó trap mỗi lần (5 gọi = 5 syscall). glibc đã bỏ cache đó từ 2017 để đổi lấy tính đúng. Đừng tin sự thật nhớ được về hệ thống — đo trên máy thật.
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.