Bài giảng Hệ điều hành - Định thời CPU

 P1 16 Shortest Remaining Time First (SRTF)* Tránh trường hợp các process có thời gian thực thi dài độc chiếm CPU Cần phải quản lý thời gian thực thi còn lại của các process Có thời gian quay vòng tốt hơn SJF Process có thời gian thực thi ngắn có độ ưu tiên cao Priority Scheduling* Mỗi process sẽ được gán một độ ưu tiên CPU sẽ được cấp cho process có độ ưu tiên cao nhất Định thời sử dụng độ ưu tiên có thể: Preemptive hoặc Nonpreemptive Gán độ ưu tiên* SJF là một giải thuật định thời sử dụng độ ưu tiên với độ ưu tiên là thời-gian-sử-dụng-CPU-dự-đoán Gán độ ưu tiên còn dựa vào: Yêu cầu về bộ nhớ Số lượng file được mở Tỉ lệ thời gian dùng cho I/O trên thời gian sử dụng CPU Các yêu cầu bên ngoài ví dụ như: số tiền người dùng trả khi thực thi công việc Priority Scheduling* Vấn đề: trì hoãn vô hạn định – process có độ ưu tiên thấp có thể không bao giờ được thực thi Giải pháp: aging – độ ưu tiên của process sẽ tăng theo thời gian Round Robin (RR)* Hàm lựa chọn: giống FCFS Round Robin (RR)* Chế độ quyết định: preemptive Khoảng thời gian tối đa cho phép (thường 10 - 100 ms) được đảm bảo bằng việc sử dụng timer interrupt Process đang chạy hết thời gian sẽ được chuyển về cuối của hàng đợi ready Round Robin (RR)* 	Process	Burst time (ms) 	P1	53 	P2	17 	P3	68 	P4	24 Quantum time = 20 ms Giản đồ Gantt:  Thường có thời gian quay vòng cao hơn SJF, nhưng lại có thời gian đáp ứng tốt hơn Round Robin (RR)* Thời gian phục vụ trung bình = Thông năng = Thời gian quay vòng = Kiểm tra lại: Thời gian đợi = (thời gian quay vòng  thời gian phục vụ  dispatch latency) Quantum time cho Round Robin Quantum time và chuyển ngữ cảnh Quantum time càng nhỏ thì càng có nhiều lần chuyển ngữ cảnh (context switch) Số lần ngưng/tiếp tục quá trình Thời gian quay vòng và quantum time Thời gian quay vòng trung bình (average turnaround time) không chắc sẽ được cải thiện khi quantum lớn Quantum time cho Round Robin* Khi thực hiện process switch thì OS sẽ sử dụng CPU chứ không phải process của người dùng (OS overhead) Dừng thực thi, lưu tất cả thông tin, nạp thông tin của process sắp thực thi Performance tùy thuộc vào kích thước của quantum time (còn gọi là time slice), và hàm phụ thuộc này không đơn giản Time slice ngắn thì đáp ứng nhanh Vấn đề: có nhiều chuyển ngữ cảnh. Phí tổn sẽ cao. Time slice dài hơn thì throughput tốt hơn (do giảm phí tổn OS overhead) nhưng thời gian đáp ứng lớn Nếu time slice quá lớn, RR trở thành FCFS. Quantum time cho Round Robin Quantum time và thời gian cho process switch: Nếu quantum time = 20 ms và thời gian cho process switch = 5 ms, như vậy phí tổn OS overhead chiếm 5/25 = 20% Nếu quantum = 500 ms, thì phí tổn chỉ còn  1% Nhưng nếu có nhiều người sử dụng trên hệ thống và thuộc loại interactive thì sẽ thấy đáp ứng rất chậm Tùy thuộc vào tập công việc mà lựa chọn quantum time Time slice nên lớn trong tương quan so sánh với thời gian cho process switch Ví dụ với 4.3 BSD UNIX, time slice là 1 giây Round Robin Nếu có n process trong hàng đợi ready, và quantum time là q, như vậy mỗi process sẽ lấy 1/n thời gian CPU theo từng khối có kích thước lớn nhất là q Sẽ không có process nào chờ lâu hơn (n - 1)q đơn vị thời gian RR sử dụng một giả thiết ngầm là tất cả các process đều có tầm quan trọng ngang nhau Không thể sử dụng RR nếu muốn các process khác nhau có độ ưu tiên khác nhau Round Robin: nhược điểm Các process dạng CPU-bound vẫn còn được “ưu tiên” Ví dụ: Một I/O-bound process sử dụng CPU trong thời gian ngắn hơn quantum time và bị blocked để đợi I/O. Và Một CPU-bound process chạy hết time slice và lại quay trở về hàng đợi ready queue (ở phía trước các process đã bị blocked) Multilevel Queue Scheduling* Trường hợp các quá trình có thể được phân thành nhóm (ví dụ: interactive và batch) Hàng đợi ready sẽ được chia thành nhiều hàng đợi riêng rẽ. Ví dụ: foreground (cho công việc cần giao tiếp - interactive) background (cho công việc dạng bó - batch) Mỗi hàng đợi sẽ có giải thuật định thời riêng. Ví dụ: foreground: dùng RR background: dùng FCFS Multilevel Queue Scheduling* Định thời cần phải thực hiện giữa các hàng đợi với nhau Theo cách cố định (fixed priority scheduling) – ví dụ: phục vụ tất cả các process của foreground rồi mới đến background Có khả năng xảy ra trì hoãn vô hạn định (starvation) Chia thời gian (time slice) – mỗi hàng đợi sẽ được lấy một khoảng sử dụng CPU nhất định để định thời cho các process của mình. Ví dụ: 80% cho foreground (dùng RR) 20% cho background (dùng FCFS) Multilevel Queue Scheduling* Ví dụ phân nhóm các quá trình Multilevel Feedback Queue* Process có thể di chuyển giữa các queue tùy theo đặc tính của nó. Ví dụ: Nếu một process sử dụng CPU quá lâu, nó sẽ bị di chuyển sang một hàng đợi có độ ưu tiên thấp hơn Nếu một process chờ qua lâu trong một hàng đợi có độ ưu tiên thấp, nó sẽ được di chuyển lên hàng đợi có độ ưu tiên cao hơn (aging, giúp tránh starvation) Multilevel Feedback Queue* Ví dụ: Có 3 hàng đợi Q0 , dùng RR với quantum 8 ms Q1 , dùng RR với quantum 16 ms Q2 , dùng FCFS Giải thuật Công việc mới sẽ vào hàng đợi Q0. Khi đến lượt mình, công việc sẽ được một khoảng thời gian là 8 milli giây. Nếu không kết thúc được trong 8 milli giây, công việc sẽ được đưa xuống hàng đợi Q1 Tại Q1, tương tự công việc sau khi chờ sẽ được cho một khoảng thời gian thực thi là 16 milli giây. Nếu hết thời gian này vẫn chưa kết thúc sẽ bị chuyển sang Q2 Multilevel Feedback Queue Multilevel Feedback Queue được xác định bởi các thông số Có bao nhiêu hàng đợi? Với mỗi queue sử dụng giải thuật định thời nào? Xác định thời điểm thăng cấp cho một process? Làm sao để xác định thời điểm giáng cấp một process? Xác định được hàng đợi nào process sẽ vào khi process đó cần thực thi? Policy và Mechanism Rất quan trọng trong định thời và phân phối tài nguyên Policy Điều gì (what) nên (hay cần) làm Mechanism Làm sao (how) để làm điều đó Ví dụ Policy: tất cả người dùng cần được công bằng Mechanism: sử dụng round robin Policy: công việc được trả tiền cao có độ ưu tiên cao Mechanism: sử dụng các giải thuật có preemptive Định thời trên hệ thống multiprocessor Nếu có nhiều CPU thì có thể thực hiện việc chia tải Phức tạp hơn so với định thời trên một processor Làm sao để chia tải? Asymmetric multiprocessor Một master processor sẽ thực hiện định thời cho tất cả các processor còn lại Symmetric multiprocessor (SMP) Hoặc mỗi processor có một hàng đợi ready riêng và bộ định thời riêng Hoặc có một hàng đợi ready chung cho tất cả processors Một processor được chọn làm scheduler cho các processor khác Hoặc mỗi processor có bộ định thời riêng và tự chọn process từ hàng đợi chung để thực thi Processor affinity Khi một process chạy trên một processor, có một số dữ liêu được cache trên bộ nhớ cache của processor Khi một process được di dời sang một processor khác Cache của processor mới phải được repopulated Cache của processor cũ phải được invalidated  vấn đề phí tổn Cân bằng tải Một processor có quá nhiều tải, trong khi những bộ xử lý khác thì lại rảnh Cân bằng tải sử dụng: Push migration: một task đặc biệt sẽ định kỳ kiểm tra tải trên tất cả các processors và công việc sẽ được đẩy đến processor rảnh Pull migration: processor rảnh sẽ lấy công việc từ processor đang bận Một số hệ thống (ví dụ Linux) hiện thực cả hai Cần phải có sự cân bằng giữa load balancing và processor affinity Đánh giá giải thuật định thời CPU Deterministic modeling Định nghĩa trước một tập tải (workload) và khảo sát performance của các giải thuật trên cùng tập tải đó Không tổng quát Queuing models Sử dụng queuing theory để phân tích giải thuật Sử dụng nhiều giả thiết để phục vụ việc phân tích Không sát thực tế Mô phỏng (simulation) Xây dựng bộ mô phỏng và chạy thử Với tập tải giả (thường được sinh tự động) Hoặc tập tải được ghi nhận từ thực tế Hiện thực Viết mã của giải thuật và test nó trong hệ thống thực Tổng kết* Sự thực thi của một process Bộ định thời chọn một process từ hàng đợi ready Dispatcher thực hiện switching Các tiêu chí định thời (thường xung đột nhau) Độ lợi CPU, thời gian chờ, thời gian đáp ứng, thông năng,… Các giải thuật định thời FCFS, SJF, Priority, RR, Multilevel Feedback Queue,… Định thời trên hệ thống multiprocessor (đọc thêm) Processor affinity và cân bằng tải Đánh giá giải thuật (đọc thêm) Mô hình, mô phỏng, hiện thực Một số vấn đề bàn thêm Cách làm tốt nhất là adaptive Để thực hiện tối ưu hoàn toàn thì cần phải tiên đoán đúng tương lai (!) Thực tế thì đa số các giải thuật lại cho kết quả gán độ ưu tiên cao nhất cho các process có nhu cầu ít nhất Vấn đề định thời có xu hướng chuyển sang “tweak and see” Các tiêu chí nào nên tối ưu? Có rất nhiều, tùy vào hệ thống, ngữ cảnh mà chọn lựa Tham khảo Operating System Concepts. Sixth Edition. John Wiley & Sons, Inc. 2002. Silberschatz, Galvin, Gagne. Modern Operating Systems. Second Edition. Prentice Hall. 2001. Andrew S. Tanenbaum. Bài tập (1) Process	Burst Time 	P1	10 	P2 	29 	P3	 3 	P4	 7 	P5	 	12 Tất cả đều đến ở thời điểm 0 Xét các giải thuật FCFS, SFJ, và RR với quantum time = 10 Giải thuật nào cho Thời gian đợi trung bình nhỏ nhất? Thông năng cao nhất? Thời gian quay vòng trung bình của process nhỏ nhất? Bài tập (2) FCFS: thời gian đợi trung bình là 28 milli giây, hãy tính các thông số khác Bài tập (3) SJF (nonpreemptive): thời gian đợi trung bình là 13 milli giây, hãy tính các thông số khác Bài tập (4) RR: thời gian đợi trung bình là 23 milli giây, hãy tính các thông số khác Giả lập bộ định thời CPU Định thời trong Linux Hai giải thuật: chia sẻ thời gian (time-sharing) và thời gian thực (real-time) Chia sẻ thời gian (time-sharing) Ưu tiên dựa trên credit: process có nhiều credit nhất sẽ được chọn để thực thi Khi có một ngắt thời gian credit sẽ bị giảm Khi credit = 0, process khác sẽ được chọn Khi tất cả các process có credit = 0, thực hiện recrediting dựa vào các yếu tố như độ ưu tiên và lịch sử (history) Định thời trong Linux Thời gian thực (real-time) Thời gian thực mềm (soft real-time) Tương thích Posix.1b compliant – có 2 lớp FCFS và RR Process có độ ưu tiên cao nhất được thực thi trước tiên