Tưởng bộ lập lịch chỉ đại khái công bằng, ai may thì được nhiều CPU? Tôi đo: CFS chia CPU chính xác 1/N cho mỗi tiến trình (lệch dưới 2%) và không bỏ đói ai — nhưng cái giá của công bằng là độ trễ: mỗi tiến trình chờ tới lượt, với 4 tiến trình là ~15ms. Công bằng tổng phần khác phản hồi nhanh.
Tưởng ghim luồng vào lõi luôn nhanh hơn vì giữ cache nóng? Tôi đo: ghim một luồng bận đơn lẻ chẳng giúp gì (còn chậm 5,3%) — bộ lập lịch vốn đã không di trú nó. Affinity chỉ đáng ở ca đặc thù: giảm giao tiếp chéo lõi (69ns mỗi round-trip), real-time, NUMA.
Tưởng select, poll, epoll như nhau chỉ khác cú pháp API? Tôi đo: select/poll là O(N) — quét cả danh sách fd mỗi lần, poll bung từ 1,9µs (100 fd) lên 203µs (10.000 fd); epoll O(1) phẳng ~130ns bất kể N, nhanh gấp 1.540 lần ở 10.000 fd. Bề mặt giống nhau, độ phức tạp thì không.
Tưởng đặt fd non-blocking thì I/O nhanh hơn? Tôi đo: một read non-blocking cùng tốc độ read thường (đều ~120ns một syscall), và non-blocking một mình là busy-loop đốt gần trọn một lõi (58ms CPU) — nó chỉ có ích khi ghép epoll để một luồng phục vụ nhiều kết nối.
Tưởng /proc rẻ như đọc một biến nên poll thoải mái? Tôi đo: mỗi lần đọc /proc/self/stat tốn 1342ns — 13 lần một syscall, hàng nghìn lần một đọc biến — vì /proc là filesystem ảo, mỗi lần đọc là 3 syscall cộng nhân sinh text tươi, không hề được cache, rồi bạn còn phải parse.
Tưởng lấy giờ luôn cùng giá, và clock nào cũng đo thời lượng được? Tôi đo: chi phí chênh ~10 lần (COARSE 3ns thô, vDSO 13ns mịn, CPU-time 140ns phải vào nhân), và CLOCK_REALTIME có thể nhảy (NTP chỉnh giờ) cho ra thời lượng âm — đo khoảng thời gian phải dùng CLOCK_MONOTONIC.