Giới thiệu về hệ điều hành
Này Habr! Theo quan điểm của tôi, tôi muốn giới thiệu với các bạn một loạt bài viết-bản dịch của một nền văn học thú vị - OSTEP. Tài liệu này thảo luận khá sâu về công việc của các hệ điều hành giống unix, cụ thể là làm việc với các tiến trình, các bộ lập lịch khác nhau, bộ nhớ và các thành phần tương tự khác tạo nên một hệ điều hành hiện đại. Bạn có thể xem bản gốc của tất cả các tài liệu ở đây . Xin lưu ý rằng bản dịch được thực hiện không chuyên nghiệp (khá tự do), nhưng tôi hy vọng tôi vẫn giữ được ý nghĩa chung.
Phòng thí nghiệm về chủ đề này có thể được tìm thấy ở đây:
Những khu vực khác:
Bạn cũng có thể xem kênh của tôi tại =)
Lập kế hoạch: Hàng đợi phản hồi đa cấp
Trong bài giảng này, chúng ta sẽ nói về các vấn đề phát triển một trong những cách tiếp cận nổi tiếng nhất để
quy hoạch, được gọi là Hàng đợi phản hồi đa cấp (MLFQ). Bộ lập lịch MLFQ được mô tả lần đầu tiên vào năm 1962 bởi Fernando J. Corbató trong một hệ thống có tên là
Hệ thống chia sẻ thời gian tương thích (CTSS). Những tác phẩm này (kể cả những tác phẩm sau này về
Multics) sau đó đã được đề cử cho Giải thưởng Turing. Bộ lập lịch đã
sau đó đã được cải thiện và có được diện mạo có thể tìm thấy ở
một số hệ thống hiện đại.
Thuật toán MLFQ cố gắng giải quyết 2 vấn đề chồng chéo cơ bản.
Thứ nhất, nó cố gắng tối ưu hóa thời gian quay vòng, như chúng ta đã thảo luận trong bài giảng trước, được tối ưu hóa bằng phương pháp bắt đầu ở đầu hàng đợi nhất
nhiệm vụ ngắn. Tuy nhiên, hệ điều hành không biết quá trình này hoặc quá trình kia sẽ chạy trong bao lâu và điều này
kiến thức cần thiết cho việc vận hành các thuật toán SJF, STCF. thứ hai, MLFQ cố gắng
làm cho hệ thống phản hồi nhanh chóng đối với người dùng (ví dụ: đối với những người ngồi và
nhìn chằm chằm vào màn hình trong khi chờ công việc hoàn thành) và do đó giảm thiểu thời gian
phản ứng. Thật không may, các thuật toán như RR làm giảm thời gian phản hồi, nhưng
có ảnh hưởng xấu đến thước đo thời gian hoàn thành. Do đó vấn đề của chúng ta là: Làm thế nào để thiết kế
bộ lập lịch sẽ đáp ứng yêu cầu của chúng tôi và đồng thời không biết gì về
bản chất của quá trình nói chung? Làm thế nào người lập lịch có thể tìm hiểu các đặc điểm của nhiệm vụ,
mà nó khởi chạy và do đó đưa ra quyết định lập kế hoạch tốt hơn?
Bản chất của vấn đề: Làm thế nào để lập kế hoạch sắp xếp nhiệm vụ nếu không có kiến thức hoàn hảo?
Cách thiết kế bộ lập lịch đồng thời giảm thiểu thời gian phản hồi
cho các nhiệm vụ tương tác, đồng thời giảm thiểu thời gian xử lý mà không biết
kiến thức về thời gian thực hiện nhiệm vụ?
Lưu ý: rút kinh nghiệm từ các sự kiện trước
Hàng đợi MLFQ là một ví dụ điển hình về hệ thống được huấn luyện trên
sự kiện trong quá khứ để dự đoán tương lai. Những cách tiếp cận như vậy thường
được tìm thấy trong hệ điều hành (Và nhiều ngành khoa học máy tính khác, bao gồm cả các ngành
dự đoán phần cứng và thuật toán bộ nhớ đệm). Các chuyến đi bộ đường dài tương tự
kích hoạt khi nhiệm vụ có các giai đoạn hành vi và do đó có thể dự đoán được.
Tuy nhiên, người ta nên cẩn thận với kỹ thuật này vì việc dự đoán rất dễ dàng.
có thể trở nên sai lầm và khiến hệ thống đưa ra những quyết định tồi tệ hơn
sẽ không có kiến thức gì cả.
MLFQ: Quy tắc cơ bản
Hãy xem xét các quy tắc cơ bản của thuật toán MLFQ. Và mặc dù việc triển khai thuật toán này
có một số, các cách tiếp cận cơ bản là tương tự nhau.
Trong quá trình triển khai mà chúng tôi sẽ xem xét, MLFQ sẽ có một số
hàng đợi riêng biệt, mỗi hàng đợi sẽ có mức độ ưu tiên khác nhau. Bất cứ lúc nào,
nhiệm vụ sẵn sàng để thực thi nằm trong cùng một hàng đợi. MLFQ sử dụng các ưu tiên,
để quyết định tác vụ nào sẽ chạy để thực thi, tức là nhiệm vụ cao hơn
mức độ ưu tiên (một tác vụ từ hàng đợi có mức độ ưu tiên cao nhất) sẽ được khởi chạy ở lần đầu tiên
xếp hàng.
Tất nhiên, có thể có nhiều tác vụ trong một hàng đợi cụ thể, vì vậy
nên họ sẽ có cùng mức độ ưu tiên. Trong trường hợp này sẽ sử dụng cơ chế
RR cho việc lập kế hoạch khởi động trong số các nhiệm vụ này.
Vì vậy chúng ta đi đến hai quy tắc cơ bản cho MLFQ:
- Quy tắc1: Nếu mức độ ưu tiên(A) > Mức độ ưu tiên(B), nhiệm vụ A sẽ chạy (B sẽ không)
- Quy tắc2: Nếu mức độ ưu tiên(A) = Mức độ ưu tiên(B), A&B được bắt đầu bằng RR
Dựa trên những điều trên, các yếu tố chính để lập kế hoạch MLFQ là
là những ưu tiên. Thay vì đưa ra mức độ ưu tiên cố định cho mỗi
nhiệm vụ, MLFQ thay đổi mức độ ưu tiên tùy thuộc vào hành vi được quan sát.
Ví dụ: nếu một tác vụ liên tục thoát khỏi CPU trong khi chờ đầu vào bàn phím,
MLFQ sẽ giữ mức độ ưu tiên của quy trình ở mức cao vì đó là cách
quá trình tương tác sẽ hoạt động. Ngược lại, nếu nhiệm vụ là liên tục và
sử dụng nhiều CPU trong thời gian dài, MLFQ sẽ hạ cấp nó
một ưu tiên. Do đó, MLFQ sẽ nghiên cứu hành vi của các tiến trình khi chúng đang chạy
và hành vi sử dụng.
Hãy vẽ một ví dụ về hàng đợi có thể trông như thế nào tại một thời điểm nào đó
thời gian và sau đó bạn nhận được một cái gì đó như thế này:
Trong sơ đồ này, 2 tiến trình A và B nằm trong hàng đợi có mức ưu tiên cao nhất. Quá trình
C ở đâu đó ở giữa và tiến trình D ở cuối hàng đợi. Theo như trên
mô tả thuật toán MLFQ, bộ lập lịch sẽ chỉ thực thi các tác vụ có mức cao nhất
mức độ ưu tiên theo RR, còn nhiệm vụ C, D sẽ không làm được.
Đương nhiên, ảnh chụp nhanh tĩnh sẽ không cung cấp bức tranh hoàn chỉnh về cách hoạt động của MLFQ.
Điều quan trọng là phải hiểu chính xác hình ảnh thay đổi như thế nào theo thời gian.
Nỗ lực 1: Cách thay đổi mức độ ưu tiên
Tại thời điểm này, bạn cần quyết định MLFQ sẽ thay đổi mức độ ưu tiên như thế nào
nhiệm vụ (và do đó là vị trí của nhiệm vụ trong hàng đợi) trong vòng đời của nó. Vì
về điều này, bạn cần lưu ý quy trình làm việc: một lượng nhất định
các tác vụ tương tác với thời gian chạy ngắn (và do đó phát hành thường xuyên
CPU) và một số tác vụ dài sử dụng CPU trong suốt thời gian làm việc của chúng, trong khi
thời gian đáp ứng cho các nhiệm vụ như vậy là không quan trọng. Và vì vậy bạn có thể thực hiện lần thử đầu tiên
thực hiện thuật toán MLFQ với các quy tắc sau:
- Quy tắc 3: Khi một tác vụ vào hệ thống, nó sẽ được xếp vào hàng đợi có giá trị cao nhất
- sự ưu tiên.
- Quy tắc4a: Nếu một tác vụ sử dụng toàn bộ cửa sổ thời gian của nó thì tác vụ đó
- mức độ ưu tiên được hạ xuống.
- Quy tắc4b: Nếu một Tác vụ giải phóng CPU trước khi khoảng thời gian của nó hết hạn thì tác vụ đó sẽ
- vẫn có cùng mức độ ưu tiên.
Ví dụ 1: Một tác vụ chạy dài
Như bạn có thể thấy trong ví dụ này, nhiệm vụ khi nhập học được đặt ở mức cao nhất
sự ưu tiên. Sau khoảng thời gian 10ms, quy trình sẽ bị hạ mức độ ưu tiên.
Người lập kế hoạch. Sau cửa sổ thời gian tiếp theo, nhiệm vụ cuối cùng sẽ bị hạ cấp xuống
mức độ ưu tiên thấp nhất trong hệ thống, nơi nó vẫn còn.
Ví dụ 2: Chọn một nhiệm vụ ngắn
Bây giờ hãy xem một ví dụ về cách MLFQ sẽ cố gắng tiếp cận SJF. Trong đó
ví dụ: hai nhiệm vụ: A, là một nhiệm vụ chạy liên tục trong thời gian dài
chiếm CPU và B, đây là một nhiệm vụ tương tác ngắn. Giả định
rằng A đã chạy được một thời gian trước khi nhiệm vụ B đến.
Biểu đồ này cho thấy kết quả của kịch bản. Nhiệm vụ A, giống như bất kỳ nhiệm vụ nào,
việc sử dụng CPU ở mức thấp nhất. Nhiệm vụ B sẽ đến vào thời điểm T=100 và sẽ
được đặt trong hàng đợi có độ ưu tiên cao nhất. Vì thời gian chạy ngắn nên
nó sẽ hoàn thành trước khi đến hàng đợi cuối cùng.
Từ ví dụ này, nên hiểu mục tiêu chính của thuật toán: vì thuật toán không
biết một nhiệm vụ dài hay ngắn thì trước hết anh ta cho rằng nhiệm vụ đó
ngắn và ưu tiên cao nhất. Nếu đây là một nhiệm vụ thực sự ngắn thì
nó sẽ thực thi nhanh chóng, nếu không nếu đó là một nhiệm vụ dài thì nó sẽ di chuyển chậm
được ưu tiên giảm xuống và sẽ sớm chứng minh rằng cô ấy thực sự là một nhiệm vụ lâu dài không
yêu cầu một phản hồi.
Ví dụ 3: Còn I/O thì sao?
Bây giờ hãy xem một ví dụ I/O. Như đã nêu trong quy tắc 4b,
nếu một tiến trình giải phóng bộ xử lý mà chưa sử dụng hết thời gian của bộ xử lý,
thì nó vẫn ở mức ưu tiên như cũ. Mục đích của quy tắc này khá đơn giản.
- ví dụ: nếu công việc tương tác thực hiện nhiều I/O, chờ đợi
từ thao tác nhấn phím hoặc chuột của người dùng, tác vụ như vậy sẽ giải phóng bộ xử lý
trước cửa sổ được phân bổ. Chúng tôi không muốn bỏ qua một nhiệm vụ ưu tiên như vậy,
và do đó nó sẽ vẫn ở mức tương tự.
Ví dụ này cho thấy thuật toán sẽ hoạt động như thế nào với các quy trình như vậy - tác vụ tương tác B, chỉ cần CPU trong 1 mili giây trước khi thực thi
Quá trình I/O và một công việc dài A, sử dụng CPU mọi lúc.
MLFQ giữ tiến trình B ở mức ưu tiên cao nhất vì nó tiếp tục
giải phóng CPU. Nếu B là một tác vụ tương tác thì thuật toán trong trường hợp này đã đạt
mục đích của nó là khởi chạy các tác vụ tương tác một cách nhanh chóng.
Các vấn đề với thuật toán MLFQ hiện tại
Trong các ví dụ trước, chúng tôi đã xây dựng phiên bản cơ bản của MLFQ. Và có vẻ như anh ấy
thực hiện công việc của nó tốt và công bằng, phân bổ thời gian CPU một cách công bằng giữa
nhiệm vụ dài và cho phép nhiệm vụ ngắn hoặc nhiệm vụ được truy cập nhiều
vào I/O để xử lý nhanh chóng. Thật không may, cách tiếp cận này có chứa một số
vấn đề nghiêm trọng.
Thứ nhất, vấn đề đói khát: nếu hệ thống có nhiều tương tác
các tác vụ, chúng sẽ tiêu tốn toàn bộ thời gian của CPU và do đó không mất nhiều thời gian
nhiệm vụ sẽ không có cơ hội được thực hiện (họ đang đói).
thứ hai, người dùng thông minh có thể viết chương trình của họ để
đánh lừa người lên lịch. Sự lừa dối nằm ở việc làm điều gì đó để ép buộc
bộ lập lịch để cung cấp cho quá trình nhiều thời gian CPU hơn. Thuật toán đó
được mô tả ở trên khá dễ bị tấn công bởi những cuộc tấn công như vậy: trước khi hết khoảng thời gian
qua, bạn cần thực hiện thao tác I/O (đối với một số, bất kể tệp nào)
và do đó giải phóng CPU. Hành vi như vậy sẽ cho phép bạn ở trong tình trạng tương tự
hàng đợi và một lần nữa nhận được phần trăm thời gian CPU lớn hơn. Nếu xong
điều này đúng (ví dụ: chạy 99% thời gian của cửa sổ trước khi giải phóng CPU),
một nhiệm vụ như vậy có thể đơn giản là độc chiếm bộ xử lý.
Cuối cùng, một chương trình có thể thay đổi hành vi của nó theo thời gian. Những nhiệm vụ đó
sử dụng CPU có thể trở nên tương tác. Trong ví dụ của chúng tôi, tương tự
các nhiệm vụ sẽ không nhận được sự xử lý thích hợp từ người lập lịch trình, như những nhiệm vụ khác sẽ
(bản gốc) nhiệm vụ tương tác.
Câu hỏi dành cho khán giả: những cuộc tấn công nào vào bộ lập lịch có thể được thực hiện trong thế giới hiện đại?
Nỗ lực 2: Tăng mức độ ưu tiên
Hãy thử thay đổi các quy tắc và xem liệu chúng ta có thể tránh được các vấn đề với
chết đói. Chúng ta có thể làm gì để đảm bảo rằng
Các tác vụ của CPU sẽ có thời gian (ngay cả khi không lâu).
Là một giải pháp đơn giản cho vấn đề, bạn có thể đề xuất định kỳ
tăng mức độ ưu tiên của tất cả các nhiệm vụ như vậy trong hệ thống. Có rất nhiều cách
để đạt được điều này, hãy thử triển khai một điều đơn giản làm ví dụ: dịch
tất cả các nhiệm vụ cùng một lúc ở mức ưu tiên cao nhất, do đó có quy tắc mới:
- Rule5: Sau khoảng thời gian S, chuyển tất cả các tác vụ trong hệ thống lên hàng đợi cao nhất.
Quy tắc mới của chúng tôi giải quyết được hai vấn đề cùng một lúc. Đầu tiên, các quá trình
đảm bảo không bị chết đói: các nhiệm vụ ở hàng đợi cao nhất sẽ được chia sẻ
thời gian xử lý theo thuật toán RR và do đó tất cả các tiến trình sẽ nhận được
thời gian xử lý. Thứ hai, nếu một số quy trình được sử dụng trước đây
chỉ bộ xử lý mới có khả năng tương tác, nó sẽ vẫn ở trong hàng đợi có hiệu suất cao nhất
mức độ ưu tiên sau khi nhận được mức tăng ưu tiên một lần lên mức cao nhất.
Hãy xem xét một ví dụ. Trong trường hợp này, hãy xem xét một quy trình đơn lẻ sử dụng
CPU và hai quy trình ngắn, tương tác. Ở bên trái của hình, hình này hiển thị hành vi không tăng mức độ ưu tiên và do đó, tác vụ chạy dài bắt đầu cạn kiệt sau khi hai tác vụ tương tác xuất hiện trên hệ thống. Trong hình bên phải, cứ sau 50ms thì mức độ ưu tiên lại được thực hiện và do đó tất cả các quy trình được đảm bảo nhận được thời gian của bộ xử lý và sẽ được khởi động định kỳ. 50ms trong trường hợp này được lấy làm ví dụ, thực tế con số này có phần cao hơn.
Rõ ràng là việc bổ sung thời gian tăng định kỳ S dẫn đến
câu hỏi logic: giá trị nào nên được đặt? Một trong những điều xứng đáng
kỹ sư hệ thống John Ousterhout gọi các đại lượng tương tự trong hệ thống là voo-doo
không đổi, vì theo một cách nào đó, chúng yêu cầu ma thuật đen để có được kết quả chính xác
phơi bày. Và thật không may, S lại có hương vị như vậy. Nếu bạn cũng đặt giá trị
nhiệm vụ lớn - dài sẽ chết đói. Và nếu bạn đặt nó quá thấp,
các tác vụ tương tác sẽ không nhận được thời gian CPU thích hợp.
Nỗ lực 3: Kế toán tốt hơn
Bây giờ chúng ta có thêm một vấn đề cần giải quyết: làm thế nào để không
cho phép gian lận lịch trình của chúng tôi? Thủ phạm của khả năng này là
quy tắc 4a, 4b cho phép công việc giữ mức độ ưu tiên bằng cách giải phóng bộ xử lý
trước khi hết thời gian quy định. Làm thế nào để đối phó với điều này?
Giải pháp trong trường hợp này có thể được coi là tính toán tốt hơn thời gian CPU trên mỗi
cấp độ MLFQ. Thay vì quên thời gian chương trình đã sử dụng
bộ xử lý trong khoảng thời gian được phân bổ, bạn nên tính đến và lưu nó. Sau đó
quá trình đã sử dụng hết thời gian quy định, nó sẽ bị hạ cấp xuống quá trình tiếp theo
mức độ ưu tiên. Bây giờ không quan trọng quá trình sẽ sử dụng thời gian như thế nào - làm thế nào
liên tục tính toán trên bộ xử lý hoặc dưới dạng một tập hợp các lệnh gọi. Như vậy,
quy tắc 4 nên được viết lại như sau:
- Rule4: Sau khi một tác vụ đã sử dụng hết thời gian được phân bổ trong hàng đợi hiện tại (bất kể nó đã giải phóng CPU bao nhiêu lần), mức độ ưu tiên của tác vụ đó sẽ giảm (nó di chuyển xuống hàng đợi).
Hãy xem một ví dụ:
»
Hình minh họa điều gì sẽ xảy ra nếu bạn cố đánh lừa người lập lịch trình như
nếu đúng với quy tắc 4a trước đó, 4b sẽ là kết quả ở bên trái. Với cái mới
quy tắc là kết quả ở bên phải. Trước khi được bảo vệ, bất kỳ tiến trình nào cũng có thể gọi I/O trước khi hoàn thành và
do đó thống trị CPU, sau khi kích hoạt bảo vệ, bất kể hành vi
I/O, anh ta vẫn sẽ xếp hàng và do đó sẽ không thể gian lận
chiếm tài nguyên CPU.
Cải thiện MLFQ và các vấn đề khác
Với những cải tiến trên, các vấn đề mới nảy sinh: một trong những vấn đề chính
câu hỏi - làm thế nào để tham số hóa một bộ lập lịch như vậy? Những thứ kia. Nên là bao nhiêu
hàng đợi? Kích thước của cửa sổ chương trình trong hàng đợi là bao nhiêu? Làm sao
chương trình thường phải được ưu tiên để tránh nạn đói và
có tính đến sự thay đổi trong hành vi của chương trình không? Đối với những câu hỏi này, không có cách nào đơn giản
phản hồi và chỉ thử nghiệm với tải và cấu hình tiếp theo
lịch trình có thể dẫn đến một số cân bằng thỏa đáng.
Ví dụ: hầu hết việc triển khai MLFQ đều cho phép bạn chỉ định các
khe thời gian cho các hàng đợi khác nhau. Hàng đợi có mức độ ưu tiên cao thường
khoảng thời gian ngắn. Những hàng đợi này bao gồm các nhiệm vụ tương tác,
chuyển đổi giữa khá nhạy và phải mất 10 hoặc ít hơn
bệnh đa xơ cứng. Ngược lại, hàng đợi có mức độ ưu tiên thấp bao gồm các tác vụ chạy dài sử dụng
CPU. Và trong trường hợp này, khoảng thời gian dài rất phù hợp (100 mili giây).
Trong ví dụ này, có 2 tác vụ đã hoạt động ở hàng đợi có mức độ ưu tiên cao 20
ms chia thành các cửa sổ 10ms. 40ms ở hàng đợi giữa (cửa sổ 20ms) và ở hàng đợi có mức độ ưu tiên thấp
khoảng thời gian xếp hàng trở thành 40 mili giây khi các tác vụ đã hoàn thành công việc của mình.
Việc triển khai MLFQ của Hệ điều hành Solaris là một lớp các bộ lập lịch chia sẻ thời gian.
Bộ lập lịch sẽ cung cấp một tập hợp các bảng xác định chính xác cách thực hiện
thay đổi mức độ ưu tiên của quy trình trong suốt vòng đời của nó, kích thước sẽ là bao nhiêu?
cửa sổ được phân bổ và tần suất nâng cao mức độ ưu tiên của nhiệm vụ. Người quản lý
hệ thống có thể tương tác với bảng này và làm cho bộ lập lịch hoạt động
khác nhau. Theo mặc định, bảng này có 60 hàng đợi với mức tăng dần
kích thước cửa sổ từ 20ms (mức độ ưu tiên cao) đến vài trăm ms (mức độ ưu tiên thấp nhất) và
cũng với việc tăng cường tất cả các nhiệm vụ một lần mỗi giây.
Các bộ lập lịch MLFQ khác không sử dụng bảng hoặc bất kỳ
các quy tắc được mô tả trong chương này, ngược lại, chúng tính toán mức độ ưu tiên bằng cách sử dụng
các công thức toán học. Ví dụ: bộ lập lịch trong FreeBSD sử dụng công thức cho
tính toán mức độ ưu tiên của nhiệm vụ hiện tại dựa trên mức độ thực hiện của quy trình
đã sử dụng CPU. Ngoài ra, việc sử dụng CPU giảm dần theo thời gian và do đó
Vì vậy, mức độ ưu tiên tăng lên có phần khác so với mô tả ở trên. Điều này đúng
gọi là thuật toán phân rã. Kể từ phiên bản 7.1, FreeBSD sử dụng bộ lập lịch ULE.
Cuối cùng, nhiều người lập kế hoạch có các tính năng khác. Ví dụ, một số
người lập lịch dành mức độ cao hơn cho hoạt động của hệ điều hành và do đó
Do đó, không có tiến trình người dùng nào có thể có mức độ ưu tiên cao nhất trong
hệ thống. Một số hệ thống cho phép bạn đưa ra lời khuyên để giúp đỡ
người lập lịch trình để ưu tiên chính xác. Ví dụ, sử dụng lệnh tốt đẹp
bạn có thể tăng hoặc giảm mức độ ưu tiên của một nhiệm vụ và do đó tăng hoặc giảm
giảm cơ hội của chương trình đối với thời gian của CPU.
MLFQ: Tóm tắt
Chúng tôi đã mô tả một phương pháp lập kế hoạch được gọi là MLFQ. Tên của anh ấy
được kết luận theo nguyên tắc hoạt động - nó có một số hàng đợi và sử dụng phản hồi
để ưu tiên một nhiệm vụ.
Hình thức cuối cùng của các quy tắc sẽ như sau:
- Rule1: Nếu mức độ ưu tiên(A) > Mức độ ưu tiên(B), tác vụ A sẽ chạy (B sẽ không)
- Rule2: Nếu mức độ ưu tiên(A) = Mức độ ưu tiên(B), A&B được bắt đầu bằng RR
- Rule3: Khi một tác vụ vào hệ thống, nó sẽ được xếp vào hàng đợi có mức độ ưu tiên cao nhất.
- Rule4: Sau khi một tác vụ đã sử dụng hết thời gian được phân bổ trong hàng đợi hiện tại (bất kể nó đã giải phóng CPU bao nhiêu lần), mức độ ưu tiên của tác vụ đó sẽ giảm (nó di chuyển xuống hàng đợi).
- Rule5: Sau khoảng thời gian S, chuyển tất cả các tác vụ trong hệ thống lên hàng đợi cao nhất.
MLFQ thú vị vì lý do sau - thay vì đòi hỏi kiến thức về
trước bản chất của nhiệm vụ, thuật toán tìm hiểu hành vi trong quá khứ của nhiệm vụ và đặt
ưu tiên phù hợp. Vì vậy, anh ấy cố gắng ngồi trên hai chiếc ghế cùng một lúc - để đạt được hiệu suất cho các nhiệm vụ nhỏ (SJF, STCF) và thực hiện các nhiệm vụ dài một cách trung thực,
Công việc tải CPU. Do đó, nhiều hệ thống, bao gồm BSD và các dẫn xuất của chúng,
Solaris, Windows, Mac sử dụng một số dạng thuật toán làm bộ lập lịch
MLFQ làm cơ sở.
Tài liệu bổ sung:
- (tin học)
Nguồn: www.habr.com