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.
Tưởng nanosleep(1µs) ngủ đúng 1µs? Tôi đo: yêu cầu 1µs thực ngủ 15,8µs (gấp 16 lần!), 10µs thành 60µs — có một cái sàn ~15µs vì đánh thức một luồng là cả một lần lập lịch lại. Ngủ ≥100µs mới sát; muốn trễ dưới µs phải busy-spin, đốt CPU.