Hệ điều hành nhìn từ hiệu năng thật

1 Một system call tốn 103ns — 450 lần một phép tính; nhưng clock_gettime chỉ 12,7ns vì không vào nhân Tưởng getpid() được glibc cache nên gần như free, và hàm nào trông như syscall cũng vào kernel? Tôi đo: một syscall thật ~103ns (450× một phép tính), getpid glibc không còn cache nên vẫn 100ns, còn clock_gettime qua vDSO chỉ 12,7ns vì chạy hẳn trong user mode. 'Trông như syscall' không quyết định giá. 03/09/2026 · 8 phút đọc

2 fork chỉ tốn 74µs dù cha giữ gì — nhưng cấp 256MB trước rồi fork lại chậm 1,86 lần Tưởng fork đắt vì phải sao chép cả bộ nhớ? Tôi đo: Copy-on-Write nên fork KHÔNG chép dữ liệu — chỉ 74µs, 1,6 lần một luồng. Nhưng CoW không làm fork miễn phí theo kích thước: fork sau khi cấp 256MB chậm 1,86 lần vì vẫn phải nhân đôi bảng trang. CoW cắt chép dữ liệu, không cắt chép bảng trang. 03/09/2026 · 8 phút đọc

3 fork rẻ nhờ Copy-on-Write, nhưng lần GHI đầu vào mỗi trang tốn 909ns — 96 lần ghi sau Tưởng sau fork con đọc/ghi đều như thường, và Copy-on-Write gần như miễn phí? Tôi đo: đọc trang rẻ (15,6ns) nhưng lần ghi đầu vào mỗi trang tốn 909ns — 96 lần lần ghi sau — vì mỗi trang phải chịu một CoW fault (bẫy, cấp trang, chép 4KB). CoW không free, chỉ hoãn cái giá chép. 03/09/2026 · 8 phút đọc

4 Binary động nhỏ hơn 12 lần nhưng khởi động CHẬM hơn — vì exec không chỉ 'nhảy vào' Tưởng exec chỉ là nhảy vào chương trình mới nên tức thì? Tôi đo: execve tốn 45,6µs cho binary tĩnh (nạp ELF, ánh xạ segment), và 73,5µs cho binary động — chậm 1,61 lần dù file nhỏ hơn 12 lần, vì trình liên kết ld.so phải phân giải symbol trước main. Nhỏ trên đĩa không bằng nhanh lúc chạy. 03/09/2026 · 8 phút đọc

5 Chuyển ngữ cảnh giữa hai tiến trình chỉ đắt hơn hai luồng 1,09 lần — sách cũ nói sai chỗ nào Tưởng chuyển ngữ cảnh giữa hai tiến trình đắt hơn nhiều so với giữa hai luồng vì phải flush TLB? Tôi đo: chỉ 1,09 lần (579ns vs 532ns) — CPU hiện đại gắn ASID/PCID nên đổi bảng trang không cần flush. Nhưng đó chỉ là chi phí trực tiếp; khác biệt thật ngoài đời là gián tiếp (cache nguội). 03/09/2026 · 8 phút đọc

6 Chạm 30.000 trang nhưng chỉ 364 page fault — vì sao 'chia đều' cho ra sai số 6 lần Tưởng mmap/malloc xong là có bộ nhớ dùng ngay, và đo chi phí fault chỉ cần chạm trang rồi chia số trang? Tôi đo: một minor fault ~368ns, nhưng rusage lộ ra chỉ 364 fault cho 30.000 trang vì huge page gom 512 trang mỗi fault — chia đều thành 58ns là sai gần 6 lần. Phải đếm số fault thật. 03/09/2026 · 8 phút đọc

7 malloc 256KB chỉ 10ns dù 'sách nói phải dùng mmap' — vì ngưỡng mmap của glibc là động Tưởng malloc lớn (>128KB) luôn dùng mmap nên chậm ngang mmap trực tiếp? Tôi đo: malloc 256KB chỉ 10ns vì ngưỡng mmap của glibc là động — nó giữ khối trong arena để tái dùng; ép phải mmap thì thành 1445ns (chậm 116×). malloc nhanh vì tái dùng, không phải phép màu. 03/09/2026 · 8 phút đọc

8 Dữ liệu nằm sẵn trong cache mà vẫn chậm 1,52 lần — thủ phạm là cache thứ hai ai cũng quên Tưởng chỉ cache dữ liệu (L1/L2/L3) quyết định tốc độ truy cập bộ nhớ? Còn một cache thứ hai: TLB — cache dịch địa chỉ. Cùng vùng 67MB, dữ liệu và cache y hệt, chỉ đổi trang 4KB sang huge page 2MB đã nhanh 1,52 lần — ~19ns chênh là TLB miss thuần. 03/09/2026 · 8 phút đọc

9 Huge page không 'luôn nhanh hơn': vùng nhỏ chỉ 1,13 lần, và mỗi page fault khựng 40µs Tưởng bật huge page thì luôn nhanh hơn, một tinh chỉnh miễn phí? Tôi đo: nó chỉ giúp khi TLB là nút thắt — vùng 0,3MB vừa TLB chỉ nhanh 1,13 lần, phải tới 67MB vượt TLB mới thắng 1,66 lần. Và có mặt trái: mỗi page fault huge phải zero cả 2MB, khựng ~40µs — 105 lần một fault thường. 03/09/2026 · 7 phút đọc

10 Đọc file lần hai chạy ở 39 GB/s — vì nó không hề chạm đĩa (và O_DIRECT lại chậm nhất) Tưởng đọc file thì luôn chạm đĩa nên chậm? Tôi đo: lần đọc thứ hai được page cache phục vụ từ RAM ở 39 GB/s — không chạm đĩa, nhanh 4,3 lần đọc nguội. Còn O_DIRECT cố ý bỏ qua cache nên chậm NHẤT — 'gần phần cứng' không có nghĩa 'nhanh hơn'. 03/09/2026 · 8 phút đọc

11 write() báo thành công không nghĩa dữ liệu đã trên đĩa — mất điện là mất, và test không bắt được Tưởng write() xong là dữ liệu đã an toàn trên đĩa? Tôi đo: write() chỉ copy vào page cache (RAM) rồi trả về ngay — nhanh 7 lần so với ép lên đĩa bằng fsync, nhưng dữ liệu chưa bền, mất điện trước write-back là mất sạch. 'Đã ghi' và 'đã bền' là hai chuyện khác nhau. 03/09/2026 · 8 phút đọc

12 Gom 256 ghi rồi fsync một lần: nhanh 125 lần mà vẫn bền — 'an toàn hay nhanh' là câu hỏi sai Tưởng phải chọn giữa an toàn (fsync mỗi ghi) và nhanh (không fsync)? Tôi đo: gom 256 ghi rồi fsync một lần cho 194 nghìn ghi/giây — nhanh 125 lần fsync-mỗi-ghi — mà vẫn bền. Chi phí fsync tính theo mỗi lần gọi, không theo lượng byte, nên group commit phá thế lưỡng nan. 03/09/2026 · 8 phút đọc

13 mmap 'nhanh gấp 5 lần read' là do tôi đo ẩu — đo công bằng chỉ 1,7 lần (nhưng ngẫu nhiên thắng 12,8 lần) Tưởng mmap luôn nhanh hơn read 5 lần vì tránh copy? Con số 5 lần đó là do đo không công bằng — mmap chỉ chạm 1 byte mỗi trang. Cho cả hai chạm hết dữ liệu, mmap chỉ nhanh 1,7 lần khi đọc tuần tự; nhưng ở truy cập ngẫu nhiên mmap thắng lớn 12,8 lần vì không syscall mỗi lần. 03/09/2026 · 8 phút đọc

14 Pipe đạt 9 GB/s — nhưng ghi từng byte chỉ 6 MB/s, và khối 64KB lại CHẬM hơn 4KB Tưởng pipe chậm, và khối càng to throughput càng cao? Tôi đo: pipe đạt 9,17 GB/s với khối 4KB nhưng ghi từng byte chỉ 6 MB/s (mỗi byte một syscall), và khối 64KB (bằng cả bộ đệm) lại chậm hơn 4KB ba lần. Độ trễ round-trip 17,7µs vì mỗi bàn giao hai bên ngủ/thức — không phải vì pipe chậm. 03/09/2026 · 8 phút đọc

15 Unix socket 'bỏ qua stack mạng nên nhanh hơn TCP' — huyền thoại không sống sót phép đo Tưởng Unix socket nhanh hơn hẳn TCP loopback vì bỏ qua stack mạng? Tôi đo: độ trễ gần như hòa (~9,5µs mỗi chiều, cùng do chi phí đánh thức tiến trình), còn throughput TCP loopback thậm chí nhanh hơn. Unix socket vẫn hơn ở tính năng — không cổng, phân quyền file, truyền fd — chứ không phải tốc độ. 03/09/2026 · 8 phút đọc

16 Một signal tốn 489ns — gấp 1.600 lần một cờ atomic, đừng dùng nó làm kênh báo hiệu Tưởng signal là cách rẻ, nhanh để báo hiệu giữa tiến trình? Tôi đo: một signal tốn 489ns — gần 5 lần một syscall và 1.600 lần một cờ atomic — vì mỗi lần nhân phải ngắt luồng, lưu ngữ cảnh, dựng khung handler rồi sigreturn. Signal là cho sự kiện hiếm, không phải kênh tần suất cao. 03/09/2026 · 8 phút đọc

17 nice không làm tiến trình chạy nhanh hơn — trên máy rảnh nó vô nghĩa hoàn toàn Tưởng nice thấp thì chạy nhanh hơn theo tỉ lệ, và nice luôn có tác động? Tôi đo: nice chỉ chia CPU khi bão hòa — hai tiến trình trên 10 lõi rảnh, nice 0 vs 19 vẫn 50/50; và tác động phi tuyến, chênh 5 gần như không đổi, phải chênh 19 mới lệch 21 lần. nice là công cụ chia phần, không phải nút tăng tốc. 03/09/2026 · 8 phút đọc

18 CFS chia CPU đều tới dưới 2% — nhưng 'công bằng' không có nghĩa 'phản hồi ngay' 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. 03/09/2026 · 8 phút đọc

19 Ghim luồng vào lõi để 'giữ cache nóng' không giúp gì — còn chậm 5,3% 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. 03/09/2026 · 8 phút đọc

20 Ở 10.000 kết nối, epoll nhanh gấp 1.540 lần poll — vì một cái là O(N), cái kia O(1) 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. 03/09/2026 · 8 phút đọc

21 Non-blocking I/O không nhanh hơn — dùng một mình nó đốt trọn một lõi CPU 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. 03/09/2026 · 8 phút đọc

22 Đọc /proc trông như đọc file, nhưng đắt gấp 13 lần một syscall — đừng poll nó liên tục 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. 03/09/2026 · 8 phút đọc

23 Đo thời lượng bằng đồng hồ tường là bug chực chờ — dùng nhầm clock, kết quả ra số âm 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. 03/09/2026 · 8 phút đọc

24 nanosleep(1µs) thực ra ngủ 16µs — chữ 'nano' nói về đối số, không về độ chính xác 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. 03/09/2026 · 10 phút đọc

25 Vòng lặp sleep(1ms) trôi 61ms sau 200 nhịp — timer định kỳ đúng phải dùng kỳ hạn tuyệt đối Tưởng lặp nanosleep(period) là timer định kỳ chính xác? Tôi đo: nó trôi 61ms sau 200 tick 1ms (lệch 30,6% mỗi chu kỳ!) vì sai số dồn lại, còn timerfd/setitimer giữ kỳ hạn tuyệt đối nên drift không tích lũy (setitimer mất đúng 0,1% tick). Khác biệt là bản chất. 03/09/2026 · 9 phút đọc

26 Shared memory zero-copy vẫn THUA Unix socket — vì sao IPC nhanh nhất lại không nhanh nhất Tưởng shared memory tự nó là IPC nhanh nhất vì zero-copy? Tôi đo: shm một-buffer lockstep chỉ 14 GB/s, THUA cả Unix socket 21 GB/s (phải copy nhưng chồng lấn được); chỉ khi dùng ring buffer lock-free (24 GB/s) shm mới thắng. Zero-copy là cần, chưa đủ. 03/09/2026 · 9 phút đọc

27 sem_wait không phải lúc nào cũng là syscall — cùng một lời gọi chênh nhau 4.800 lần Tưởng mỗi sem_wait là một syscall đắt nên phải né semaphore ở đường nóng? Tôi đo: khi bộ đếm còn dương, sem_wait chỉ là một phép atomic ~1,8 ns, chẳng vào nhân; chỉ khi phải ngủ mới tốn ~8.695 ns (futex + chuyển ngữ cảnh) — chênh gần 4.800 lần. Cái đắt là phải ngủ, không phải cái tên hàm. 03/09/2026 · 8 phút đọc

28 mlock không làm RAM nhanh hơn — nó là lời hứa, không phải nút tăng tốc Tưởng mlock khóa trang vào RAM thì truy cập nhanh hơn? Tôi đo: đọc một trang đã resident tốn y hệt (~0,6 ns/dòng-cache dù có mlock hay không). mlock chỉ prefault (bỏ page fault lần đầu, 8,3 vs 68,6 ns) và đảm bảo không swap — hai thứ về sự chắc chắn, không về tốc độ. 03/09/2026 · 8 phút đọc

29 malloc 48GB trên máy 8GB vẫn thành công — vì sao kiểm malloc==NULL gần như vô dụng Tưởng malloc trả non-NULL nghĩa là bạn thật sự có bộ nhớ đó? Tôi đo: malloc 48GB trên máy 8GB vẫn thành công (RSS chỉ ~1MB), RAM thật chỉ tốn lúc chạm — và chạm quá giới hạn thì OOM killer bắn chết tiến trình bằng SIGKILL (exit 137), không hề trả NULL cho bạn bắt. 03/09/2026 · 9 phút đọc

30 Cùng một malloc(1MB) chênh nhau 166 lần — bí mật nằm ở chỗ nó có chạm nhân hay không Tưởng cấp phát stack và heap tốn ngang nhau, hoặc malloc luôn đắt vì gọi OS? Tôi đo: stack ~1ns (chỉ trừ con trỏ), malloc/free ~5-12ns mà chẳng syscall lần nào (glibc giữ block để tái dùng), và cùng một malloc(1MB) chênh 166 lần tùy có chạm nhân hay không. 03/09/2026 · 8 phút đọc

31 Free 10.000 block xong RSS vẫn y nguyên — vì sao free không trả RAM về OS Tưởng mỗi malloc gọi brk xin OS, và free trả RAM về OS? Tôi đo: malloc mọc heap theo lô ~132KB (hàng nghìn malloc chẳng syscall lần nào), và free block nhỏ KHÔNG trả về OS — break lẫn RSS đều không tụt, glibc giữ lại để tái dùng. Đây không phải rò rỉ. 03/09/2026 · 8 phút đọc

32 Thêm luồng CPU-bound làm chậm gấp 4 — 1843 lần bị tước CPU dù không luồng nào block Tưởng context switch chỉ xảy ra khi luồng block, và sched_yield giúp chạy nhanh hơn? Tôi đo: workload CPU thuần không hề block vẫn bị tước CPU cưỡng bức (nivcsw 0→1843 khi luồng vượt số lõi), thời gian tăng gấp 2–4 lần — còn yield một mình chỉ là một syscall 150ns vô ích. 03/09/2026 · 8 phút đọc

33 Luồng ưu tiên cao nhất chờ khóa 468ms vì một luồng trung bình — bug suýt giết Mars Pathfinder Tưởng ưu tiên cao thì luôn được chạy trước? Tôi dựng lại đúng bug Mars Pathfinder: luồng cao nhất bị chặn 468ms bởi một luồng trung bình — gián tiếp, qua một cái khóa. Bật priority inheritance, thời gian chờ tụt còn 128ms (giảm 73%). 03/09/2026 · 9 phút đọc

34 SCHED_FIFO không làm code nhanh hơn — nó cắt jitter 3ms xuống 12µs Tưởng đặt luồng vào lịch thời gian thực thì nó chạy nhanh hơn? Tôi đo: SCHED_FIFO không tăng tốc CPU một chút nào — nó cắt jitter độ trễ đánh thức dưới tải từ 3ms xuống 12µs (256 lần). Đổi lại, một luồng FIFO không block đói sạch mọi luồng thường, có thể treo cả máy. 03/09/2026 · 9 phút đọc

35 --cpus=0.5 chậm gấp đôi dù 9 lõi ngồi không — cgroup là trần cứng, không phải nice Tưởng giới hạn CPU của cgroup giống nice, chỉ cắn khi máy bận? Tôi đo: --cpus=0.5 vẫn chậm 2,2 lần và --cpus=0.25 chậm 6,5 lần dù 9/10 lõi ngồi không. Nó là hạn ngạch tuyệt đối, không phải ưu tiên — và ở hạn ngạch nhỏ còn tệ hơn tỉ lệ. 03/09/2026 · 8 phút đọc

36 Syscall đắt hơn gọi hàm 139 lần — mà getpid gần như không làm gì Tưởng gọi một lời gọi hệ thống cũng như gọi một hàm thường? Tôi đo thử: vượt ranh giới user→kernel tốn 103ns so với hàm user 0,74ns (139 lần) — và vDSO không vượt ranh giới chỉ 13ns, chứng tỏ chính cú vượt ranh giới là chi phí, không phải việc nhân làm. Nên giảm chi phí = vượt ít lần hơn. 03/09/2026 · 8 phút đọc

37 Tối ưu NUMA trên máy 1 node = tối ưu hư vô: đo topology trước đã Tưởng cứ dùng numactl là tối ưu, và malloc quyết định trang RAM nằm ở đâu? Tôi đo topology thật: môi trường này 0 NUMA node nên hiệu ứng remote/local không quan sát được — và bài học lớn nhất là đo topology trước; còn trên máy nhiều node, first-touch (không phải malloc) mới quyết định. 03/09/2026 · 8 phút đọc

38 Zero-copy (sendfile) không nhanh hơn — nhưng dùng nửa CPU Tưởng zero-copy (sendfile) luôn nhanh hơn read+write? Tôi đo thử: throughput gần như bằng nhau khi memory-bound (21 vs 22ms), nhưng sendfile dùng nửa CPU (17,3 vs 35,4ms) vì bỏ hai lần copy sang user-space. Lợi ích thật là CPU (gấp đôi công suất), không phải tốc độ một lần truyền. 03/09/2026 · 8 phút đọc

39 printf không phải một syscall mỗi lần: đệm stdio nhanh hơn 116 lần Tưởng mỗi putc/fprintf là một syscall, và stdout luôn được đệm như nhau? Tôi đo thử: stdio đệm trong user-space nên có đệm nhanh hơn không đệm 116 lần (10 triệu write() vs 2442); và mặc định đệm khác nhau tùy stdout là file, pipe hay terminal — thứ quyết định cả tốc độ lẫn output có mất khi crash. 03/09/2026 · 8 phút đọc

40 Cùng 800MB, đọc tuần tự nhanh gấp đôi ngẫu nhiên — ngay cả trong RAM Tưởng đọc cùng lượng byte thì tuần tự hay ngẫu nhiên cũng như nhau, và trong cache thì hết khác biệt? Tôi đo thử: cùng 800MB, tuần tự nhanh 2,15 lần ngay cả khi file đã trong page cache (readahead + locality) — và trên đĩa vật lý thật gap còn khổng lồ hơn nhiều vì seek. 03/09/2026 · 7 phút đọc

41 'Random Access Memory' mà truy cập ngẫu nhiên chậm 423 lần: sức mạnh prefetch Tưởng truy cập RAM nào cũng như nhau (Random Access Memory), và prefetch chỉ giúp đọc stride 1? Tôi đo thử: duyệt mảng tuần tự 0,28ns/phần tử vs ngẫu nhiên 107ns — chênh 423 lần, vì prefetcher phần cứng chỉ đoán được mẫu ĐỀU; cái giết nó là tính không đoán được, không phải khoảng cách. 03/09/2026 · 8 phút đọc

42 78MB trong 20.000 file nhỏ chậm gấp 4 lần một file lớn — dù cùng byte Tưởng đọc cùng lượng byte thì nhiều file nhỏ hay một file lớn cũng như nhau? Tôi đo thử: 20000 file nhỏ chậm 4 lần một file lớn cùng byte; và 20000 file 4KB với 20000 file 512B (ít hơn 8 lần dữ liệu) tốn ngang nhau — chi phí là per-file, không per-byte. 03/09/2026 · 8 phút đọc

43 VSZ 3GB mà RSS chỉ 1MB: đọc đúng bộ nhớ tiến trình trong top Tưởng VSZ là bộ nhớ tiến trình dùng, và cộng RSS các tiến trình ra tổng RAM? Tôi đo thử: malloc 3GB chưa chạm cho VSZ ~3GB nhưng RSS chỉ ~1MB; và RSS 1016KB nhưng PSS chỉ 453KB vì trang thư viện chia sẻ bị đếm đủ trong RSS. Ba con số, ba nghĩa — chọn nhầm là hiểu sai hoàn toàn. 03/09/2026 · 7 phút đọc

44 Chạy một lần rồi so là sai: cùng thao tác đo ra 99,8 hay 197,9 ns tùy nhiễu Tưởng chạy một lần trước/sau là đủ biết một tinh chỉnh có tác dụng? Tôi đo thử: cùng một getpid không đổi gì, một phép đo có thể ra 99,8 hoặc 197,9 ns (chênh 2 lần) tùy nhiễu; chỉ min-của-nhiều-lần mới tái lập, và phải cô lập đúng một biến. Đây là nền của mọi con số trong sê-ri. 03/09/2026 · 8 phút đọc

45 45 phần đo hệ điều hành, gói lại: thang độ trễ 36.000 lần và 4 cái bẫy trực giác Tổng kết 45 phần đo thật hệ điều hành trong container Linux: một thang độ trễ trải ~36.000 lần (từ 0,25ns đọc RAM tuần tự tới 9µs đánh thức luồng), và bốn mẫu trực giác-sai lặp đi lặp lại — chi phí per-thao-tác, cái đắt là phải ngủ, cấp phát lười, đoán được hơn nhanh thô. 03/09/2026 · 7 phút đọc