Chạm 64MB bộ nhớ mới tôi tưởng gây 16.384 lỗi trang; getrusage ra 32 — vì trang lớn trong suốt (THP) 2MB, một lỗi lo trọn 2MB. Tắt THP ra đúng 16.384 (lệch 512 lần). Và đọc file đã nằm trong cache gần như không gây lỗi trang nặng nào. Kích thước trang và page cache là biến ẩn — phải đo, đừng nhẩm.
Trực giác nói 'cha chết thì con chết theo'. Tôi dựng cây tiến trình thật rồi bắn SIGKILL vào đúng PID cha: nó chết ngay, ba worker chẳng suy suyển. Vì tín hiệu không lan theo quan hệ cha–con. Muốn hạ cả cụm phải nhắm nhóm — kill(-pgid) một phát hạ tất. Đo thật trong container.
char *s="hello"; s[0]='H'; — biên dịch trót lọt, chạy thì chết. Tôi đo ba ca ghi vào trang chỉ đọc, cả ba SIGSEGV, suýt chốt 'ghi vào trang chỉ đọc thì chết'. Rồi ca thứ tư sau fork lật ngược: cùng cái bẫy phần cứng đó, kernel lại lặng lẽ copy trang chứ không giết. Đo thật trong container.
Mỗi syscall dưới strace tốn ~80 micro giây thay vì 126 nano giây — chậm 630 lần. Nghĩa là mọi con số thời gian đo được khi strace đang bám đều sai bét. Chính cái thước tin cậy nhất của tôi lại là hiệu ứng người quan sát ở dạng thuần khiết nhất. Đo thật, và một maxim của sê-ri bị lật ngược.
Đọc mã nguồn cả ngày cũng không thấy tranh chấp: hai luồng, hai biến riêng, không đụng nhau. Vậy mà chậm ~3,7 lần chỉ vì hai biến tình cờ nằm chung một cache line. Nút thắt vô hình ở tầng mã nguồn, chỉ lộ khi nhìn xuống bố trí bộ nhớ. Đo thật, và cách săn nó.
Chạy thử là root, mở file cấm-mọi-quyền vẫn thành công — root bỏ qua mọi bit, kiểm bảo mật khi là root là kiểm không gì cả. Hạ xuống user thường mới ra EACCES. Và nhân kiểm quyền MỘT LẦN lúc open: chmod 000 không thu hồi được fd đang mở, chỉ chặn open mới.