Redox OS hiện đại hóa bộ lập lịch CPU với DWRR, cải thiện hiệu suất đáng kể

Redox OS hiện đại hóa bộ lập lịch CPU với DWRR, cải thiện hiệu suất đáng kể

Redox OS, hệ điều hành mã nguồn mở viết bằng ngôn ngữ Rust, vừa có một bước tiến quan trọng trong việc tối ưu hóa hiệu suất nhân hệ thống. Trong khuôn khổ chương trình Redox Summer of Code (RSoC) 2026, nhà phát triển Akshit Gaur đã thực hiện việc hiện đại hóa hệ thống lập lịch tiến trình (process scheduling subsystem), thay thế thuật toán Round Robin truyền thống bằng Deficit Weighted Round Robin (DWRR).

Bộ lập lịch Round Robin cũ

Hạn chế của Round Robin truyền thống

Trước đây, Redox OS sử dụng bộ lập lịch Round Robin (RR) đơn giản. Để dễ hình dung, hãy tưởng tượng một quán bar với ít bartender nhưng đông khách. Bartender sẽ phục vụ khách từ trái sang phải, lặp lại vòng lặp.

Cách tiếp cận này công bằng về mặt lý thuyết: mọi người đều chờ đợi như nhau. Tuy nhiên, vấn đề nảy sinh khi có một "VIP" (ví dụ: một chính trị gia nổi tiếng) xuất hiện. Nếu bartender phục vụ họ y như khách thường, VIP sẽ tức giận vì phải chờ đợi.

Trong thế giới máy tính, "VIP" này chính là các tiến trình tương tác I/O có độ ưu tiên cao (như stack âm thanh). Nếu chúng phải chờ đợi phía sau các tác vụ ngốn CPU (CPU-hogging) nền, hệ thống sẽ trở nên ì ạch, gây ra hiện tượng giật lag hoặc tiếng méo tiếng. Thuật toán RR cũ không có cơ chế phân biệt ưu tiên, dẫn đến trải nghiệm người dùng kém khi hệ thống bị tải nặng.

Giải pháp mới: Deficit Weighted Round Robin (DWRR)

Để giải quyết vấn đề trên, DWRR được giới thiệu với cơ chế phân bổ tài nguyên dựa trên trọng số (weight). Hãy tiếp tục ví dụ về quán bar: giờ đây có 3 hàng đợi (A, B, C) tương ứng với tốc độ cấp token khác nhau (1, 2, 4 token/giây). Khách ở hàng C (ưu tiên cao nhất) sẽ có đủ tiền để mua bia nhanh hơn hàng A.

Kết quả benchmark với DWRR

Khi một tiến trình ưu tiên cao (VIP) đến, nó được đưa vào hàng đợi C và được phục vụ ngay lập tức. Điều này giúp các tác vụ quan trọng được xử lý nhanh chóng, cải thiện đáng kể độ phản hồi của hệ thống.

Tuy nhiên, DWRR thuần túy gặp phải vấn đề "đói" tài nguyên (starvation). Nếu hàng đợi C luôn có khách, các hàng đợi A và B sẽ không bao giờ được phục vụ.

Cải tiến với Interleaved DWRR

Để cân bằng giữa hiệu suất và sự công bằng, Akshit Gaur đã áp dụng phương pháp xen kẽ (Interleaved). Thay vì để hàng đợi ưu tiên cao chiếm dụng CPU cho đến khi hết hạn mức (balance), bộ lập lịch sẽ phục vụ VIP một vòng, sau đó kiểm tra ngay xem các hàng đợi ưu tiên thấp hơn có đủ token để thực thi một tác vụ nhỏ hay không, rồi mới quay lại phục vụ VIP.

Mặc dù phương pháp này làm tăng nhẹ chi phí chuyển đổi ngữ cảnh (context-switch overhead), nhưng nó mang lại lợi ích to lớn về độ trễ (latency) và đảm bảo không có tiến trình nào bị bỏ lại phía sau quá lâu.

Kết quả thực nghiệm và hiệu năng

Các bài kiểm tra cho thấy sự cải thiện rõ rệt so với bộ lập lịch cũ:

• Tăng FPS: Trong demo 3D pixelcannon của Redox, khi chạy cùng hai tác vụ ngốn CPU nền, bộ lập lịch mới giúp tăng thêm khoảng 150 FPS so với RR cũ.
• Tăng tốc độ xử lý: Các tác vụ bị giới hạn bởi CPU (CPU-bound) thấy tốc độ xử lý tăng gấp 1.5 lần.
• Độ phản hồi: Công cụ đo lường schedrs (bản viết lại bằng Rust của schbench) cho thấy sự cải thiện vượt trội về độ trễ пробужд và số lượng thao tác mỗi giây (ops/sec).

Cụ thể, trong các bài kiểm tra thực tế với tải nặng:

• Tác vụ tương tác (pixelcannon) được tăng độ ưu tiên (renice) giúp đạt ~1150 FPS so với mức ~1000 FPS trước đó (tăng 15%).
• Độ trễ chuyển đổi ngữ cảnh giảm mạnh, số thao tác mỗi giây tăng từ 243 lên 360 (tăng 48%).

Kết luận

Việc chuyển sang bộ lập lịch DWRR xen kẽ là một bước tiến lớn cho Redox OS. Nó cung cấp một giải pháp dung hòa giữa sự công bằng của Round Robin và hiệu suất của DWRR thuần túy, bảo vệ các tác vụ nhạy cảm về độ trễ khỏi sự nhiễu loạn của các tiến trình nền.

Trong tương lai, nhóm phát triển hướng tới việc thay thế logic hàng đợi tĩnh bằng các tính toán độ trễ động của thuật toán EEVDF đầy đủ để tiếp tục tối ưu hóa nhân hệ thống.