Tôi tưởng mỗi lần khóa mutex là một syscall vào nhân. strace 2 triệu lần khóa: 0 lệnh futex — mutex sống trong user-space, chỉ vào nhân khi tranh chấp (và cả khi đó cũng chỉ ~0,03%). Khóa không tranh chấp tốn 3,4 ns; cái đắt khi tranh chấp là cache nảy giữa các lõi, không phải syscall.
Bộ nhớ chia sẻ không chép qua nhân, đáng lẽ nhanh nhất. Nhưng bản đầu của tôi (2519 MB/s) THUA cả pipe (2755) — vì tôi ghi hết rồi mới đọc, hai lõi thay nhau ngồi không. Sửa thành vòng đệm chồng lấn: 4004 MB/s, 0 lời gọi hệ thống. Không-chép là điều kiện cần, chồng lấn mới là điều kiện đủ.
nice 19 chạy một mình vẫn được 118345 đơn vị, y hệt nice 0: nice không phải nút tốc độ mà là trọng số chia CPU, chỉ có tác dụng khi có tranh chấp. CFS chia đều một lõi (mỗi tiến trình 1/N, tổng công việc không đổi) — thêm tiến trình không nướng thêm bánh CPU.
Busy-poll nhận ra dữ liệu nhanh gấp 9 lần đọc chặn (11µs so với 97µs) — nhưng nó đốt trọn 100% một lõi CPU trong khi đọc chặn ngủ ở 0%. 'Nhanh' vô nghĩa nếu chưa hỏi 'tốn gì'. O_NONBLOCK sinh ra để ghép với epoll, không phải để quay bận ngây thơ.
malloc(500MB) trong container 100MB trả về khác NULL — overcommit đồng ý ngay. Nhưng khi tôi chạm vào bộ nhớ đó, nhân giết tiến trình bằng SIGKILL không bắt được, exit 137, memory.events ghi oom_kill=1. malloc thành công không phải bằng chứng bạn có RAM; cái chết đột ngột lúc dùng mới là sự thật.
Bốn luồng cùng tăng một biến chung 8 triệu lần, đo ra 2.144.770 — mất 73% mà không một lỗi nào báo. Thêm mutex thì đúng nhưng chậm 87 lần. __thread cho mỗi luồng bản riêng: vừa đúng vừa nhanh, truy cập gần ngang biến thường. Bản nhanh nhất lại là bản sai — 'nhanh' mà chưa 'đúng' là con số nguy hiểm nhất.