Low Latency Optimization: Understanding Huge Pages (Part 1)

Phần 1/2. Phần 2: Hudson River Trading 2022.

Hudson River Trading · 2022 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

Latency thường là yếu tố quyết định trong giao dịch thuật toán; HRT tốn nhiều công tối thiểu latency của stack giao dịch. Một khía cạnh ít được bàn sâu: huge page và TLB.
Mỗi lần truy cập bộ nhớ (cả dữ liệu lẫn lệnh, kể cả đã nằm trong cache), phần cứng phải dịch địa chỉ ảo sang địa chỉ vật lý theo từng trang. Bảng trang x86 có nhiều tầng: tra một trang 4 KiB cần ít nhất 3 lần đọc bộ nhớ phụ thuộc nhau; nếu cả ba trượt cache, với 70 ns mỗi lần là 210 ns trước khi lấy được dữ liệu.

TLB là cache phần cứng cho kết quả dịch địa chỉ. CPU server gần đây có khoảng 1.500–2.000 entry/core. Với trang 4 KiB, TLB chỉ phủ khoảng 8 MiB, nhỏ hơn cả CPU cache và nhỏ hơn nhiều working set. Với trang 2 MiB, phủ khoảng 4 GiB.
Huge page còn làm bảng trang nhỏ đi 512 lần (dễ nằm trong cache hơn) và tra cứu bớt một lần đọc, nên kể cả khi trượt TLB cũng nhanh hơn.
Benchmark nhân tạo: cấp mảng double 32 GiB rồi cộng 130 triệu phần tử ngẫu nhiên (chỉ số ghi sẵn ra file để mọi lần chạy giống nhau), trên máy Alder Lake rảnh: khởi tạo tuyến tính nhanh hơn 40%; phần truy cập ngẫu nhiên nhanh hơn 4,5 lần.

Lý tưởng là toàn bộ working set được TLB dịch mà không phải đi bảng trang; vừa giảm latency truy cập bộ nhớ vừa giải phóng chỗ trong CPU cache.
HRT nhấn mạnh huge page chỉ là một tối ưu, có thể hợp hoặc không với workload; phải benchmark trước.

Ở latency nanosecond, chi phí dịch địa chỉ là một phần đáng kể của mỗi lần truy cập bộ nhớ.
Ước lượng phạm vi phủ của TLB (số entry × kích thước trang) so với working set để biết có đáng thử huge page không.