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.
Thấy container dùng 255 trên 256 MB, tôi hoảng 'sắp OOM'. Nhưng nếu chỗ đầy đó là page cache thì container khỏe re, oom_kill=0; nếu là anon thì exit 137, bị giết ngay. Con số 'đang dùng bao nhiêu' đứng một mình gần như vô dụng — chỉ thành phần mới nói. Đo thật.
Đọc lạnh từ đĩa 93ms, đọc ấm từ cache 18ms — nhanh gấp 5 lần. Nhưng lần đầu tôi đo, hai lần bằng nhau: hóa ra ghi file bằng dd đã nạp sẵn nó vào page cache, nên 'lần đầu' của tôi vốn đã ấm. Muốn đo đọc lạnh phải drop_caches. Đo thật, và cột Cached là đèn báo.
Mỗi lượt một tiến trình chạy ~3 ms rồi bị đẩy ra, và con số đó cố định dù 2 hay 8 tiến trình tranh CPU. Nhưng lần đầu tôi không thấy chia lượt gì cả (quên ghim CPU), và thứ tôi đang đo hóa ra là EEVDF chứ không phải CFS như tên bài. Đo thật hai cú vấp về bộ lập lịch.
Đo sáu vòng lặp bằng gcc và clang: clang nhanh hơn 2-4 lần ở vài vòng, hòa ở số khác. Tôi định kết 'clang nhanh hơn' và giải thích nó thắng popcount nhờ lệnh cnt. Đọc mã máy ra ngược hẳn — gcc mới dùng cnt mà vẫn chậm. Bài cuối sê-ri, và cái bẫy tôi rơi vào cả hai chân.
Ghim hai luồng vào một nhân, chuyển ngữ cảnh chỉ 0,5us. Bỏ ghim để chúng dùng hai nhân — chậm gấp 16 lần (8,7us). Trực giác 'nhiều nhân nhanh hơn' sai bét: hai nhân không chuyển ngữ cảnh, cái tôi đo là chi phí cross-core (cache nảy + IPI). Đo thật bằng ping-pong.
Atomic fetch_add đúng là nhanh hơn mutex 2,8 lần khi một luồng. Nhưng một biến atomic chung scale ÂM: 627 tụt xuống 34 triệu/giây ở 10 luồng vì cache-line ping-pong, gần bằng mutex. Cách nhanh thật không phải khóa xịn hơn mà là không chia sẻ — đếm riêng nhanh gấp ~180 lần. Tôi đo.