推 kevin190:發文大大的第二段, 大推阿...哈哈218.171.150.218 08/14
※ 引述《saker ()》之銘言：
: ※ 引述《WYchuang (打不留歪莊)》之銘言：
: : 說到實際面 ...
: : 我只看果有某paper利用OS的排程機制來省電(某位老中的paper)
: : 理由很簡單，但是做起來頗麻煩，就是在schedule的時候
: : 把所有的task作個分析，預測一下每個task下個時間點的IO (這邊是最難的部分)
: : 然後把一樣IO的task排在一起執行，當這些一樣IO的task都跑過之後
: : 把該IO調到idle (因為暫時沒有task會需要它了)
: : 其他的都是一堆機率，看都看不懂 XD
: 看到這個我有一點疑問.....
: 基本上task的新增是隨時都有可能的吧...
: 難道每次schedule時都要重新分析一次? 這樣loading會不會太大阿
: 而且在embedded上還有硬體限制說 我之前聽老師說過 基本上
: 這種想法只能在paper寫寫而已 因為他們都是考慮理想狀況
: 要真正拿來使用幾乎不可能.....不過我沒有看過這篇paper
: 所以我也只是隨便說說而已..... :)
ㄟ ... 詳細的狀況由於年代久遠，我早忘了 :-P
不過我記得他有實做，然後還有數據的樣子 ...
: : 我只看過在即時系統的討論
: : 由於real-time sys知道每個task的最短執行時間(理論上啦)
: : 如果系統可以降速度跑，但依然可以符合此task的時間需求
: : 那就降速跑，理論上似乎可以省電
: 那降速跑的功能是作在軟體還是硬體阿
: 如果是軟體handle 那不是又要多task來處理這一件工作
: 那摸分析的task + 降速後的task 會不會反而耗電量比原task還多??
降速度跑大概是軟體決定，硬體執行 ...
(比較dynamic的東西，硬體做應該會想死吧)
你說的tradeoff應該是存在的沒錯，所以才有做paper的價值嘍
(資工的人總是在各式各樣的tradeoff當中載浮載沈啊 XD)
我自己是覺得，system的東西總是牽涉廣泛，往往牽一髮而動全身
比如說我上次去聽清大的某教授報告(專精compiler的教授)，
他說他們認為OS的low power機制一定要搭配Compiler，效果才會好
我到現在還是參不透這句話 XD
--
笑年ㄟ：老闆，這是什麼啊？這麼苦！
老闆 ：笑年ㄟ，這就是人蔘啊 ~~
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.96.129.115