Cùng một tiến trình là PID 1 nhìn từ trong namespace, PID 17 nhìn từ host — inode namespace khác nhau chứng minh đó là hai view của một tiến trình. Container không phải máy ảo: chỉ là tiến trình host với view riêng. Vì sao nhiều 'sự thật' của hệ điều hành là tương đối theo góc nhìn.
Atomic nhanh gấp 2,6 lần mutex ở một luồng (626 so với 239) — nhưng ở tám luồng atomic (25) còn thua mutex (40), và vòng CAS tự viết tụt xuống 7,5 triệu ops/giây với mười triệu lần thử lại. Lock-free không phải contention-free cũng không phải scalable; cách scale thật là giảm chia sẻ.
O_DIRECT bỏ qua page cache, đòi buffer/offset/độ dài căn lề theo khối. Nhưng việc thực thi tùy filesystem: overlayfs từ chối buffer lệch bằng EINVAL, FUSE lờ đi cho chạy, /dev/zero không mở nổi. Code thiếu căn lề chạy tốt lúc test rồi vỡ trên fs production — 'chạy được trên máy mình' là lời hứa rỗng.
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.
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 đủ.