看板 Grad-ProbAsk 關於我們 聯絡資訊
1 請問convoy effect會影響IO utilization嗎?印象中會影響CPU utilization,但是IO u tilization跟這有關嗎 2 在有號數乘法(booth)中,ALU的32bit還是64bit? 3 induction-variable access是迴圈內的變數嗎?(控制迴圈的還是迴圈內的) 同上 Write buffer scheme is similar to write-through except that write buffer schem e writes data to buffers rather than to memory. CPU also needs to wait for the completion of buffer writing but does not need to wait too long since buffer writing is much faster than memory writing. 這句哪裡有錯?buffer寫回memory的時候CPU不用等待吧?還是buffer是在記憶體? 能順便問有沒有103交大的標準答案表嗎?找了一陣子找不到 4(已解決) http://i.imgur.com/SW21yyb.jpg 有號誌控制的甘特圖該怎麼畫,在wait的時候強迫process放棄資源嗎 5 http://i.imgur.com/AiRwtqA.jpg 這題我不管怎麼想都覺得是5126... one level 多讀一次 two level 多2次 three level 多3次 我這樣想法有錯嗎@@ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.200.186 ※ 文章網址: https://www.ptt.cc/bbs/Grad-ProbAsk/M.1483251973.A.700.html ※ 編輯: newpuma (223.140.200.186), 01/01/2017 14:29:27 ※ 編輯: newpuma (223.140.200.186), 01/01/2017 15:03:19
jjjjjjjk92: 第四題p2應該會繼承p1的優先權把臨界區間執行完吧?01/01 15:19
jjjjjjjk92: 我是這樣想拉 不然不就死結了@@01/01 15:19
我忘記p2有先做一秒了...感謝xd ※ 編輯: newpuma (223.140.200.186), 01/01/2017 15:43:55
TWkobe: booth就是加強版hardware friendly, 所以32-bitALU01/01 15:49
boy00114: 1.應該跟IO沒關係吧01/01 17:40
我也覺得,但有間接影響到的可能嗎?還是io utilization有另外的算法@@ ※ 編輯: newpuma (223.140.200.186), 01/01/2017 18:04:20
aa06697: convoy effect不會影響cpu利用度反而是影響IO利用度吧? 01/01 18:07
aa06697: 應該是說有沒有影響利用度要看那個長時間的process在做什 01/01 18:07
aa06697: 麼(如果說他真的在算東西 那CPU利用度是很高的) 而影響 01/01 18:07
aa06697: IO是肯定有的 好幾個IO bound job 都被CPU bound job卡住 01/01 18:07
aa06697: 了 IO利用度當然就低了 我的想法喇有誤還請更正 01/01 18:07
jjjjjjjk92: 我是覺得沒影響使用率不管IO還是CPU 使用率是使用時間 01/01 18:24
jjjjjjjk92: 除以閒置時間加上使用時間 不管有沒有護衛效應 都一樣 01/01 18:25
jjjjjjjk92: 影響的是個程序的平均等待時間而已吧? 01/01 18:26
aa06697: 我是覺得會影響IO喇XD 若要以那麼宏觀來看的話 利用度就 01/01 19:05
aa06697: 沒有討論的意義了 另外最後一題 一個block可以存2^11個p 01/01 19:05
aa06697: ointer 所以5120會在2level的第二個 所以5120+5(inode本 01/01 19:05
aa06697: 身, level1一個, level2三個) 01/01 19:05
aa06697: http://i.imgur.com/kWLptFI.jpg 01/01 19:08
jjjjjjjk92: 假設Ready Queue 都是IO bound process 使用FCFS CPU 01/01 19:16
jjjjjjjk92: 排班 還是有護衛效應 但此時IO使用率高 01/01 19:17
jjjjjjjk92: 我是覺得沒辦法去判斷 會不會影響 01/01 19:18
jjjjjjjk92: Ready queue 都是CPU bound 使用SJF 沒有護衛效應 01/01 19:19
jjjjjjjk92: 但是IO 使用率低落 所以根本沒辦法用護衛效應去判斷 01/01 19:19
jjjjjjjk92: 前者有護衛效應但使用率高 後者沒有 使用率卻低落 01/01 19:23
aa06697: 沒有說沒有護衛效應IO利用度就會高呀 我前面講的意思是有 01/01 19:24
aa06697: 護衛效益IO利用度就會 是單向的~ 01/01 19:24
ken52011219: 我是覺得有關係,認為convoy effect 只是 影響I/O 01/01 19:33
ken52011219: utilization 的其中一個因素,沒有convoy effect只是 01/01 19:34
ken52011219: 表示convoy effect 不會在這個scheduler algo 影響 01/01 19:36
ken52011219: 到I/O utilization 的增加或減少,只是個條件而已 01/01 19:36
ken52011219: 至於為什麼會影響,我的原因是 假設有CPU BOUND and 01/01 19:37
ken52011219: I/O BOUND processes in Ready Queue 時,I/O BOUND 01/01 19:37
ken52011219: 需要一點時間compute,因為有convoy effect ,導致 01/01 19:39
ken52011219: 原定排程I/O 在某時進入I/O QUEUE中,但因此被延後 01/01 19:40
ken52011219: 整體 I/O utilization 也跟著下降 01/01 19:40
yupog2003: 之前好像有類似的問題,我也認為有關係,理由就是k大說 01/01 19:51
yupog2003: 的那樣 01/01 19:52
ken52011219: 3. 後面那串英文 01/01 19:59
jjjjjjjk92: http://i.imgur.com/mEaTa2J.jpg 01/01 19:59
ken52011219: 錯的原因是語意不合,write buffer 最後還是會寫入 01/01 19:59
jjjjjjjk92: 我這樣算是一樣的XDD 哪裡出錯了嗎 01/01 20:00
ken52011219: memory 但題目是用 「rather than」 01/01 20:01
yupog2003: induction variable是不是就是for(i=0;i<n;i++){}的i? 01/01 20:20
ken52011219: http://i.imgur.com/h0Zex5H.jpg 01/01 20:20
yupog2003: 如果是的話,感覺induction variable是控制迴圈的 01/01 20:24
ken52011219: Convoy effect 主要是在講 單一資源被長時間把持, 01/01 20:24
ken52011219: 並且因此必須「block 」其他需要用到該資源的process 01/01 20:24
ken52011219: 簡而言之,J大的問題應該是在只考慮單一Ready Queue 01/01 20:25
ken52011219: http://imgur.com/a/zC16w 附上剛剛在網路找的 01/01 20:27
ken52011219: 只不過恐龍的確沒有正式討論 Convoy effect 是什麼啦 01/01 20:28
ken52011219: QQ~ 01/01 20:28
ken52011219: 第五題 我從交大錯到清大 從清大錯到台大 有人可以教 01/01 20:29
ken52011219: 一下嗎 0.0/ 01/01 20:30
yupog2003: 第五題:http://imgur.com/RAjdrq2 01/01 20:44
yupog2003: 其實上面aa大解過了,只是被推文海埋沒了XD 01/01 20:45
jjjjjjjk92: 感謝K大 我大概理解為什麼有影響了 XDDD 01/01 20:47
ken52011219: 所以以此類推 3 LEVEL 就是三層BLOCK囉?? 01/01 20:47
yupog2003: 是的,如果用到3 level的話,就一定要畫到第三層才可以 01/01 20:49
yupog2003: 放真正指向資料的address 01/01 20:50
ken52011219: 好的 感謝各 _(_ _)_ 01/01 20:52
ken52011219: 位 01/01 20:53