Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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.
Một mảng toàn cục 400MB làm file thực thi nhỏ như cũ (nằm .bss) — và bất ngờ hơn, lúc chạy nó chỉ tốn 1MB RAM thật cho tới khi bạn chạm vào từng trang. Kích thước file, VSZ và RSS là ba con số khác nhau. Đo thật trong container.
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ỉ.
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.
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 độ.
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.