Các kỹ sư của Meta đã đề xuất một tính năng”swqueue”của hàng công việc được chia sẻ cho bộ lập lịch CFS của nhân Linux có thể giúp cải thiện hiệu suất thông lượng nhỏ và độ trễ tốt hơn một chút, đặc biệt đối với các hệ thống AMD có nhiều CCX.
Đăng hôm nay là một”yêu cầu nhận xét”về tính năng CFS swqueue này mà các kỹ sư Meta đang làm việc. Trong trường hợp của họ, họ được thúc đẩy làm việc trên swqueue để tăng cường tính xuyên suốt trên các máy chủ AMD EPYC đang chạy các quy trình máy chủ web HHVM cho Facebook.
Một số điểm chính rút ra từ thư giới thiệu bản vá lỗi RFC của họ là:
Chúng tôi nhận thấy rằng các CPU vẫn không hoạt động ngay cả khi máy chủ được sử dụng quá mức. Để đáp lại, chúng tôi đã viết tính năng”đánh thức được chia sẻ”(swqueue) được đề xuất trong bộ bản vá này. Ý tưởng đằng sau swqueue rất đơn giản: nó cho phép bộ lập lịch hoạt động tích cực bảo tồn bằng cách đặt một tác vụ đánh thức vào hàng đợi FIFO trên mỗi LLC có thể được lấy từ một lõi khác trong hàng đợi FIFO của LLC, sau đó có thể được kéo từ trước khi nó đi. nhàn rỗi.
Với thay đổi đơn giản này, chúng tôi đã có thể đạt được mức cải thiện 1-1,6% về thông lượng, cũng như một sự cải thiện nhỏ, nhất quán về độ trễ p95 và p99, trong HHVM. Những cải tiến về hiệu suất này là kết quả bổ sung cho các chiến thắng từ các nút gỡ lỗi được đề cập ở trên.
…
Thông lượng HHVM được cải thiện ~1-1,6% cũng có thể nhìn thấy tương tự bằng cách sử dụng bộ lập lịch sched_ext tiết kiệm công việc (ngay cả những bộ rất đơn giản như FIFO toàn cầu).
Trong cả máy chủ CCX đơn và đa ổ cắm , điều này có thể cải thiện đáng kể hiệu suất. Ngoài mức tăng hiệu suất quan sát được trên khối lượng công việc web nội bộ của chúng tôi, chúng tôi cũng nhận thấy sự cải thiện trong các khối lượng công việc thông thường chẳng hạn như biên dịch kernel khi chạy Wakequeue được chia sẻ.
…
swqueue ở dạng này dường như mang lại một chiến thắng nhỏ nhưng đáng chú ý cho khối lượng công việc giới hạn CPU mặt trước trải rộng trên nhiều CCX. Lý do có vẻ khá đơn giản: swqueue khuyến khích bảo toàn công việc bên trong CCX bằng cách để CPU thực hiện thao tác kéo O(1) từ hàng đợi trên mỗi LLC gồm các tác vụ có thể chạy được. Như đã đề cập ở trên, nó bổ sung cho SIS_NODE, tìm kiếm các lõi nhàn rỗi trên đường đánh thức.Mặc dù swqueue ở dạng này khuyến khích bảo tồn công việc, nhưng tất nhiên nó không đảm bảo điều đó vì chúng tôi không triển khai bất kỳ loại công việc nào ăn cắp giữa các swqueue. Trong tương lai, chúng tôi có khả năng đẩy mức sử dụng CPU cao hơn nữa bằng cách cho phép đánh cắp công việc giữa các swqueue, có khả năng là giữa các CCX trên cùng một nút NUMA.
Bộ bản vá swqueue chỉ có hơn 200 dòng mới. mã và các bản vá RFC hiện đã sẵn sàng để xem xét trên danh sách gửi thư hạt nhân.