LV. 22
GP 1k

【討論】kernel調度的新未來-EAS

樓主 我家熊熊最可愛 tedder870906
GP31 BP-
先上手機版遮蔽圖,避免被嚇到
換張預覽圖 證明我有改過內文

這篇是獻給有夠蘿莉控的那位先森
會莫名其妙知道EAS是因為看到大佬突然提到這個

然後後來我才意識到原來幾百年前這個kernel就已經有eas了
不過最新的版本貌似把它獨立出來了
然後再加上htuhtc的u12+頻率很詭異
就抓來研究研究
下面這個是u12+的最高頻率(來源)

所以他是正港的845 可是好像是用input boost去加速的

不管他 回來eas
目前找到的資料如下(來源

最近由於Linaro 和ARM 主導的EAS(Energy Aware Scheduler) 日漸完善,屬於EAS 一部分的基於調度器的調頻技術也獲得了很多關注。本文主要介紹基於調度器的CPU 調頻策略的原理,以及當前上游社區在這一方面最新的進展。

傳統CPU 調頻策略

傳統CPU調頻模塊主要分為3塊:CPUFreq核心模塊、CPUFreq驅動和CPUFreq Governor。核心模塊主要是一些公共的邏輯和API,CPUFreq驅動是處理和平台相關的邏輯,比如設置CPU的頻率和電壓。而Governor就是我們今天要講的主角,CPU調頻的策略。CPU在什麼樣負載,什麼樣的場景下應該跑多少頻率,都是通過CPUFreq Governor採取一定策略來決定的,然後調用cpufreq_driver->target()來設置要調整的頻率。
那麼傳統CPUFreq Governor是如何選擇當前CPU的頻率的呢?performance和powersave這兩個governor就不說了,一個是讓CPU一直跑在最高頻率,另外一個是讓CPU跑在最低頻率,所有的動作都在初始化的時候做了,本身也沒有什麼策略。userspace只是實現了scaling_setspeed節點,主要策略在用戶態,也沒什麼可講的。而ondemand和conservation兩個governor則是開啟一個timer,定期去計算各個CPU的負載。當CPU負載超過80%時,ondemand就會把CPU頻率調到最高,其他情況則會根據當前負載按比例計算頻率。而對於conservation而言,CPU負載超過80%時,默認會以5%的步伐遞增;當CPU負載少於20%的時候,默認會以5%的步伐遞減1
Interactive governor並沒有合入到mainline,它是在Android中引入的。現在幾乎所有的Android手機用的都在用這個governor。所不同的是,它在每一個CPU上都註冊了一個idle notifier。當CPU退出idle狀態時,interactive就會縮減採樣頻率,從而可以快速響應負載變化。其他情況下,會根據當前CPU負載調整頻率,這一點和ondemand類似2
總結起來,對於像ondemand,conservation,interactive 含有調頻邏輯的governor,都包含一個共同的部分- 負載採樣,需要每隔一定時間就計算一次CPU 負載。而這個共同點,就是今天這篇文章的關鍵。有些人認為,對於CPU 的負載,沒有誰比調度器還清楚的了。所以cpufreq governor 完全沒必要自己去做負載採樣,應該從內核調度器那裡獲取。而基於調度器的cpufreq governor 就是這樣引出來的。

基於調度器的CPU 調頻策略

內核調度器中的CFS 調度類是通過PELT(per entity load tracking) 來統計各個Task 的負載(capacity),並映射到0 ~ 1024(最大值可在編譯時指定)。內核當中的負載均衡就是通過這些統計值來平衡各個CPU 之間的任務。而基於調度器的cpufreq governor 的主要原理就是把各個CPU 的capacity 映射到CPU 頻率,來完成調頻動作,capacity 越高,當前CPU 負載越高,所以頻率也調的很高。
而當前內核社區中,已經有兩個成形的方案。一個是ARM 和Linaro 主導的項目- cpufreq_sched,屬於EAS 的一部分。而另外一個Intel 主導的項目- schedutil。

cpufreq_sched

cpufreq_sched 3本身邏輯比較簡單,當cfs, rt, deadline 3個調度類中的capacity出現變化的時候,就調用update_cpu_capacity_request()來更新當前policy下CPU的頻率。cpufreq中的policy有可能包含多個CPU,所以這裡要選擇其中最大的capacity來代表整個policy的負載。capacity到CPU頻率,是通過如下代碼按比例轉換的:
freq_new = capacity * policy->max >> SCHED_CAPACITY_SHIFT
SCHED_CAPACITY_SHIFT一般是10,即capacity 的最大值1024。假定當前policy 允許的最大CPU 頻率是1.2GHz,capacity 為500,那麼對應的頻率是586Mhz。如果我們直接把CPU 設置在這個頻率上,會導致一些性能上的下降。所以cpufreq_sched 會在最終的capacity 基礎上,乘上1.25,相當於在當前capacity 的基礎上增加20%。
從cpufreq_sched 的實現,我們可以看到整個調頻動作,都是從調度器中直接設置下來的,cpufreq_sched 自身並沒有去統計各個CPU 的負載。而這種做法也讓CPU 的頻率可以快速的響應負載變化,理論上講,當前平台的cpufreq 驅動最小調頻間隔是多少,那麼cpufreq_sched 就可以做到多少。相比於interactive 20ms 的調頻間隔,cpufreq_sched 不到1ms 的調頻間隔簡直是天壤之別。下圖分別是interactive 和sched 在不同負載下CPU 頻率圖:

  • Interactive:Interactive
  • Cpufreq_sched:Sched
響應速度快,調頻間隔短,固然是cpufreq_sched 的優勢,但是把整個調頻動作都放到調度器裡做,無疑會增加調度器的負擔。調度器代碼路徑變長,也會增加調度器的延時。如果某個平台的cpufreq 驅動在設置CPU 頻率的時候會導致系統睡眠,那麼cpufreq_sched 還需要在每一個CPU 上額外開啟一個線程,防止對調度器造成影響。

schedutil

在介紹schedutil之前,我們首先得介紹一個內核社區最近出現的新機制- utilization update callback 4。其實就是一個各個CPU使用率變化時的一種回調機制。通過cpufreq_set_update_util_data()來註冊回調函數,當cfs, rt, deadline 3個調度類的capacity出現變化時,調用cpufreq_update_util()來觸發hook,實現類似notifier的效果。
而schedutil 5就是利用這個負載變化回調機制,通過cpufreq_add_update_util_hook()註冊回調函數,當CPU負載出現變化的時候,就會觸發schedutil sugov_update進行調頻動作。而剩下的調頻實現,其實跟cpufreq_sched大同小異。
目前來看,cpufreq_sched 好像已經被放棄,而schedutil 有望在Linux kenrel 4.7 版本中合入,到時候,內核Cpufreq Governor 又要新添一名成員了。

這裡也有提出這張圖
內文翻譯如下(本熊渣翻譯 看不懂的點進去來源自己看吧哈哈)
在2014年,ARM釋出了新的linux內核技術,稱作:Intelligent Power Allocation(IPA)
讓一個無風扇設計的SoC維持在他的額定作業溫度是相當重要的。
而當一個處理器所要處理的程序越多,它產出的熱就越多。
在八核、十核心的處理器上你時常可發現它是由高效能''大''核(像是Cortex-A72或Cortex-A57)以及節能''小''核(像是Cortex-A53或是Cortex-A35)在加上GPU。
這三個不同的部份的SoC可被個別控制而且可創造和諧的最佳電源分配方案。
這意謂著如果CPU創造出過出量的熱,那排程器可能會拜託小核減少它可以使用的電源。
而如果是GPU負載過大、而CPU卻很閒。那SoC內部就有足夠的溫度使用額度給GPU進行大量的作業,因為CPU並沒有使用它所有的配給額。

而ARM的方案被主流的Linux內核正式接受,而這樣做的受益是可觀的。
根據ARM的測試,使用IPA管理方式可增進SoC效能高達36%。
效能會向上衝的理由是SoC被持續的動態調整,使得每一分的溫度配給額都有用上。
這意謂著CPU和GPU都可以使用全速去跑。

而那已經是2014年的東西了。在2015至2016,ARM開始將Linux社群推向下一階段。稱作Energy Aware Scheduling (EAS)
而EAS是為了解決在Linux電源管理次系統中古老的兩項設計限制(CPUFreq和CPUIdle),他們兩者並不會依循排程器辦事。
事實上更糟,排程器、CPUFreq和CPUIdle完全不互相干涉,所以他們時常會意見不和。
當排程器試著平衡整個cpu上的負擔時,CPUFreq和CPUIdle次系統卻將頻率像下拉(降頻)或是讓它們閒置。

而EAS背後的想法就是將CPUFreq(如DVFS)、CPUIdle及IPA次系統整合。
這項全新的設計是基於可測量的能源模型資料,而不是原先的魔法可調數據;而且含會支持未來的CPU拓樸學(包含個別核心/個別串動態電壓和頻率調節),估計會被主流的linux內核維護。
這意謂著如果有一項新的事情等待CPU回應,EAS或許會把這項任務丟給正在運作的CPU核心而不是閒置的核心。
所以剩下的核心是不需要運作的,進而省電。
過往,當排程器只為了獲得最高效能,可能會將它丟給閒置的cpu核心,進而取得最高的效能。

最初的測試解果已經顯示出能源使用量就算維持和現在主流的linux內核運算法一樣的效能,所使用的電源已經可以明顯的降低。
事實上,有些負荷下EAS的效能可以更好。


看起來目前趨勢是要把eas整合進linux裡
然後我手機的kernel刷了他給的基於eas
變成這樣



一切都ai了起來呢
本來要更深入的探討 無奈有一隻87隱翅蟲在我面前溜走
我要回去殺蟲了

31
-
LV. 22
GP 1k
2 樓 我家熊熊最可愛 tedder870906
GP0 BP-
為了避免和內文混淆
所以把我目前感覺的打在下面
裝置為:Redmi Note 4x (3/32) w/ xposed+magisk lineage official 15.1(8.1)
因為下面說的可能是kernel的問題 所以也順便提一下 是revolt eas poc版 連結可能要去telegram或是github拿
相較原本裝的R29.5(OC)及R30來說 充電速度明顯變很慢(可能是lineage的問題 或是我電池老化了)
而日常使用上掉電速度是有變慢的,手機也較不會發燙
以目前有在玩的神魔之塔來說體驗和OC版的時候差不多,但耗電量降低了不少
剩下的就等我慢慢體驗出來吧
0
-
板務人員:

265 筆精華,08/13 更新
一個月內新增 4
歡迎加入共同維護。


face基於日前微軟官方表示 Internet Explorer 不再支援新的網路標準,可能無法使用新的應用程式來呈現網站內容,在瀏覽器支援度及網站安全性的雙重考量下,為了讓巴友們有更好的使用體驗,巴哈姆特即將於 2019年9月2日 停止支援 Internet Explorer 瀏覽器的頁面呈現和功能。
屆時建議您使用下述瀏覽器來瀏覽巴哈姆特:
。Google Chrome(推薦)
。Mozilla Firefox
。Microsoft Edge(Windows10以上的作業系統版本才可使用)

face我們了解您不想看到廣告的心情⋯ 若您願意支持巴哈姆特永續經營,請將 gamer.com.tw 加入廣告阻擋工具的白名單中,謝謝 !【教學】