※ 引述《wsx02 (無酒罐)》之銘言：
: 標題: [理工] [OS] multi-level queue
: 時間: Sat Nov 26 20:53:11 2011
:
: scheduling採multi-level queue
: process常用 就讓time slice短
: process不常用 就讓time slice長
: 請問為什麼呢?
:
這邊如果你問的multi-level queue
指的是比較常見的各層採RR
然後各queue之間可preemptive
也因為各層採RR,才有time slice大小的設計問題
大部分會將system process放在最高的priority queue
再來是iteractive
batch等等
假設你的問題是為何比較上層的queue有比較小的quantum
而比較下層的有比較大的quantum
是因為上層是屬於偏向interactive的環境
需要短的response time 來快速的回應
至於下層,屬於batch式的,比較沒有急迫性
所以採大的slice來提升cpu utilization(因context switching少)
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc)
: ◆ From: 218.166.118.244
: 推 ceo890710:如果常用的process slice長就會常常讓其他process為了等 11/26 21:02
: → ceo890710:這個process而starvation，而因為常出現，所以常常會佔 11/26 21:03
: → ceo890710:用大部分的CPU time使得CPU utilization變差。 11/26 21:04
: → ceo890710:應該是這樣吧，有錯誤請指正~ 11/26 21:04
如果他的multi-level queue跟常用不常用指的跟我上面提的一樣
即使上層的time quantum設的比較小
下層的一樣有機會starvation,跟slice大小設定無關
(有time slice大小,應該是採用RR
就不會有starvation的問題)
另外單層之間,根據不同使用頻率給予不同的process不一樣的quantum
這我就比較不了解,不過如果要討論單層應該也不用問multi level吧?
: 推 genius945:多層queue,大多是採上層具有較大優先權,而上層的process 11/26 21:04
: → genius945:大多是屬於user process,time slice短,response time也 11/26 21:05
: → genius945:會比較短,至於下層的一些如system,batch的process,則採 11/26 21:05
這邊錯了,system應該放在最上層Orz
: → genius945:比較長的time quantum來減少context switching,增加利用 11/26 21:06
: → genius945:1F講的好像比較對XDD 11/26 21:12
: 推 genius945:不對...我覺得有點怪,一直占用cpu time,utilization是會 11/26 21:14
: → genius945:比較好,我還是選我原本的答案好了XD 11/26 21:15
: 推 ceo890710:更正~我想講的是starvation這件事~跟utilization無關~ 11/26 21:27
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 218.173.192.94