- Bộ lập lịch CPU của kernel cung cấp nhiều chế độ tiền nhiệm để hiện thực sự đánh đổi giữa thông lượng hệ thống và thời gian phản hồi.
- Vào tháng 9 năm 2023, trong một cuộc thảo luận về lập lịch, khái niệm "tiền nhiệm lười (lazy preemption)" đã được đề xuất; khái niệm này có thể mang lại kết quả tốt hơn đồng thời đơn giản hóa việc lập lịch của kernel.
- Khái niệm này im ắng một thời gian, nhưng đã xuất hiện trở lại với loạt bản vá của Peter Zijlstra.
Các chế độ tiền nhiệm hiện tại của kernel
- PREEMPT_NONE: Chỉ cho phép tiền nhiệm khi tác vụ đang chạy đã dùng hết lát thời gian.
- PREEMPT_VOLUNTARY: Bổ sung nhiều điểm trong kernel nơi có thể tiền nhiệm khi cần.
- PREEMPT_FULL: Có thể tiền nhiệm ở gần như mọi điểm, ngoại trừ khi đang giữ spinlock.
- PREEMPT_RT: Ưu tiên tiền nhiệm hơn hầu hết các yếu tố khác, và khiến phần lớn mã spinlock cũng có thể bị tiền nhiệm.
Giới thiệu tiền nhiệm lười
- Bản vá tiền nhiệm lười thêm cờ mới
TIF_NEED_RESCHED_LAZY để biểu thị rằng cần lập lịch lại vào một thời điểm nào đó, thay vì ngay lập tức.
- Trong chế độ tiền nhiệm lười (PREEMPT_LAZY), phần lớn sự kiện sẽ đặt cờ mới này; khi kernel quay về không gian người dùng, nếu một trong hai cờ được đặt thì bộ lập lịch sẽ được gọi.
- Kết quả của thay đổi này là trong chế độ tiền nhiệm lười, phần lớn các sự kiện trong kernel sẽ không tiền nhiệm tác vụ hiện tại.
Loại bỏ cond_resched()
- Mục tiêu cuối cùng của công việc này là chỉ còn lại hai chế độ không thời gian thực: PREEMPT_LAZY và PREEMPT_FULL.
- Chế độ lười nằm giữa PREEMPT_NONE và PREEMPT_VOLUNTARY, và sẽ thay thế hai chế độ này.
- Hiện tại vẫn còn các lệnh gọi
cond_resched(), và chúng vẫn cần thiết chừng nào các chế độ PREEMPT_NONE và PREEMPT_VOLUNTARY còn tồn tại.
Tóm tắt của GN⁺
- Tiền nhiệm lười có thể giúp đơn giản hóa việc lập lịch của kernel và góp phần mang lại độ trễ có thể dự đoán được.
- Công việc này có thể giúp giảm kích thước kernel và đơn giản hóa mã nguồn.
- Tiền nhiệm lười cung cấp thông lượng tương tự PREEMPT_VOLUNTARY, nhưng vẫn cần thêm kiểm thử và tối ưu hóa.
- Một dự án khác có chức năng tương tự là bộ lập lịch ULE của FreeBSD.
1 bình luận
Ý kiến trên Hacker News
Kết quả cuối cùng của công việc về preemption lười là kernel trở nên nhỏ gọn và đơn giản hơn, đồng thời cung cấp độ trễ có thể dự đoán được. Điều này có vẻ là một giải pháp tốt hơn, không cần rải các lời gọi liên quan đến scheduler khắp codebase. Tuy nhiên, sẽ mất thời gian để đạt được điều đó.
Mức độ preemption cao giúp hệ thống phản hồi nhanh hơn với các sự kiện. Phản ứng nhanh với các sự kiện như chuyển động chuột hay tín hiệu "sắp tan chảy" của lò phản ứng sẽ đem lại cảm giác thỏa đáng hơn. Tuy nhiên, mức độ preemption cao có thể ảnh hưởng đến tổng thông lượng của hệ thống. Với các workload có nhiều tác vụ nặng về CPU, càng ít bị gián đoạn càng có lợi. Preemption thường xuyên hơn có thể dẫn đến mức độ tranh chấp khóa cao hơn. Vì vậy mới có nhiều chế độ khác nhau, và chế độ preemption tối ưu có lẽ sẽ phụ thuộc vào workload.
Kernel hiện tại có bốn chế độ để điều chỉnh thời điểm một tác vụ có thể bị preempt để nhường chỗ cho tác vụ khác.
Không thể tìm thấy các con số liên quan đến patch trong chuỗi thảo luận được liên kết. Hẳn đã có một số benchmark sơ bộ được thực hiện để cho thấy tiềm năng thực sự của thay đổi này.
Tôi thắc mắc scheduler gắn kết chặt với phần còn lại của mã kernel đến mức nào.
Sẽ rất tốt nếu preemption có thể thích ứng theo từng sự kiện, nhưng việc quản lý điều đó cho mọi sự kiện có thể gây hại cho tính ổn định của hệ thống. Điều này giống như việc dùng các công cụ như Tomba Finder để tạo lead.