Linux pipe nhanh đến mức nào? (2022)

• Khám phá cách Unix pipe được hiện thực trên Linux và các phương pháp tối ưu hóa chương trình kiểm thử ghi và đọc dữ liệu qua pipe
• Chương trình ban đầu có thông lượng khoảng 3,5GiB/s, và qua nhiều tối ưu hóa khác nhau đã được cải thiện lên gấp 20 lần
• Các tối ưu hóa này được thực hiện bằng cách profiling chương trình bằng công cụ perf của Linux
• Bài viết được truyền cảm hứng từ một chương trình FizzBuzz đã được tối ưu hóa có thể đẩy đầu ra vào pipe với tốc độ khoảng ~35GiB/s
• Đào sâu vào cách pipe hoạt động bên trong, lý do việc ghi và đọc từ chúng lại chậm, và cách các system call vmsplice và splice có thể cải thiện hiệu năng
• Thảo luận về cách phân trang của Linux và việc sử dụng huge pages có thể tạo ra các phiên bản chương trình nhanh hơn
• Tối ưu hóa cuối cùng bao gồm việc thay polling bằng một busy loop
• Các bài kiểm thử được thực hiện trên CPU Intel Skylake i7-8550U và Linux 5.17
• Bài viết giải thích chi tiết cách bộ nhớ được cấu thành từ các trang có kích thước cố định và cách CPU dùng page table để dịch địa chỉ ảo sang địa chỉ vật lý
• Bài viết kết luận với quan sát rằng chuyển sang huge pages trong chương trình có thể cải thiện hiệu năng khoảng 50%
• Bài viết cũng bàn về việc sử dụng huge pages trên CPU và cách giảm lỗi Translation Lookaside Buffer (TLB), điều này có thể cải thiện hiệu năng
• Mã kernel giả định rằng struct page trỏ tới một trang có kích thước chuẩn của kiến trúc hiện tại. Với huge pages, struct page ở vị trí "head" chứa thông tin về trang vật lý thực tế, còn các trang "tail" liên tiếp chỉ chứa con trỏ trỏ về trang head
• Các kernel gần đây (sau 5.17) bao gồm một kiểu mới là struct folio để nhận diện rõ ràng trang head. Điều này giúp giảm nhu cầu phải kiểm tra lúc chạy xem struct page là trang head hay tail, từ đó cải thiện hiệu năng
• Bài viết thảo luận về khái niệm busy loop để tránh chi phí đồng bộ hóa. Cách này yêu cầu vmsplice trả về khi không thể ghi vào pipe, rồi quay busy loop cho tới khi sẵn sàng. Nó có thể mang lại mức tăng hiệu năng 25%, nhưng phải đánh đổi bằng việc chiếm trọn một lõi CPU cho tới khi vmsplice sẵn sàng
• Tác giả tóm tắt các chủ đề chính được đề cập trong bài: thao tác zero-copy, ring buffer, phân trang & bộ nhớ ảo, overhead đồng bộ hóa
• Tác giả cũng thừa nhận còn nhiều tùy chọn và chi tiết khác không được bàn tới trong bài, vì chúng không liên quan hoặc không đủ thú vị với tác giả
• Bài viết được độc giả đón nhận tích cực vì họ thấy nó hữu ích và thú vị

[GN⁺]

Ý kiến trên Hacker News

• Bài viết về tốc độ của pipe trên Linux, tập trung vào vmsplice, hoạt động như một cơ chế bộ nhớ chia sẻ thu nhỏ giữa hai tiến trình
• Việc sử dụng vmsplice đòi hỏi phải xử lý bộ đệm cẩn thận khi đọc và ghi; khá phức tạp nhưng có thể hiệu quả
• Triển khai tiêu chuẩn của pipe trên Linux được cho là chậm hơn 20 lần so với tốc độ tối ưu
• Bài viết được đón nhận tích cực, độc giả khen ngợi tính nhiều thông tin của nó
• Một độc giả chỉ ra rằng pipe trên Linux có thể tạo ra hành vi mang tính quyết định, đồng thời dẫn liên kết đến nguồn bên ngoài để đọc thêm
• Có câu hỏi được đặt ra về các thư viện xử lý dữ liệu cung cấp lớp trừu tượng trên pipe, socket, file và bộ nhớ, cũng như liệu chúng có triển khai các tối ưu hóa được thảo luận trong bài hay không
• Bài viết nhắc đến các API như splice() và vmsplice(), được cho là khó dùng và ít được tận dụng trong phần lớn chương trình
• Tốc độ của pipe trên Linux được so sánh với tốc độ của một lõi đơn trong hệ thống; kernel ánh xạ cùng một trang bộ nhớ vật lý từ stdout của chương trình này sang stdin của chương trình khác, biến thao tác này thành zerocopy hoặc, trong tình huống kém tối ưu hơn, là onecopy nhanh
• Bài viết kết nối khái niệm bảng trang với việc phân tích hiệu năng bằng perf, nhấn mạnh tầm quan trọng của nó đối với thông lượng
• Một độc giả chia sẻ trải nghiệm với triển khai pipe của Cygwin, nhắc đến tốc độ chậm hơn so với Linux
• Tốc độ của pipe trên Linux được đánh giá là đủ nhanh để lặp lại và kết hợp các lệnh như cat, sed, awk, cut, grep, uniq, jq v.v.