--
To post to this group, send email to
hacking...@googlegroups.com
To unsubscribe from this group, send email to
hackingthursd...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/hackingthursday?hl=zh-TW
那誰會用一大堆的 process 呢? 有幾種
1 Server,如 apache/SMB/ftp
2 make -j xxx
3 某些支援 multi thread 的程式。
(1) 是比較可能的狀況。對於跑 server 的機器而言,這個 patch 應該會很有效。因為
20 個 httpd 會分到和 browser 一樣的時間。而不是 apache 分到 20/21 而 browser
只分到 1/21。
對 cgroups[1] 是另外一套做法,但是需要配合 userland utils 來控制。
Linus 對於類似透過 userspace+kernelspace 的解決方法不太認同,可見原 lkml
討論[4]。主要原因之一是設定過於複雜,其二最後總是難以維護 userspace/kernelspace 間的程式碼。而 automated
per tty task groups 則是 "just works",適用新、舊版 distributions.
而不用改掉或整合許多設定。
目前 cgroups 可以客製配給資源的功能更強大,像是 CPU Set/Memory Nodes[2], Block IO
Controller[3] 等等。但是必須配合配合 userland utils 使用,現有 Control Group
Configuration Library[5] 與 systemd System and Session Manager[6][7][8]
等。
其中 RedHat 比較積極推 systemd,目標是在 Fedora 15 後替換掉 Upstart. 主要開發者 Lennart
Poettering[9] 也在 LKML 上發表一個透過 cgroup 作到類似 automated per tty task
groups 一樣功能的方法[10]。
[1] http://www.google.com.tw/codesearch/p?hl=zh-TW#_3c4wX_-gBo/Documentation/cgroups/cgroups.txt
[2] http://www.google.com.tw/codesearch/p?hl=zh-TW#_3c4wX_-gBo/Documentation/cgroups/cpusets.txt
[3] http://www.google.com.tw/codesearch/p?hl=zh-TW#_3c4wX_-gBo/Documentation/cgroups/blkio-controller.txt
[4] http://groups.google.com/group/linux.kernel/msg/ffb0026ae9ceb433
[5] http://libcg.sourceforge.net/
[6] http://www.freedesktop.org/wiki/Software/systemd
[7] http://fedoraproject.org/wiki/Features/systemd
[8] http://0pointer.de/blog/projects/systemd.html
[9] http://0pointer.de/lennart/
[10] http://groups.google.com/group/linux.kernel/msg/74bc33e7d64fc86f
Regards
-Rex
Server 通常也有管理 UI。這個 patch 對有 server 上的 browser 效能應該有幫助。另外
它對 BT 可能也有幫且哦 :-) 如果這個 BT 是用 multi-thread 寫的。
不過說實在的,這個報導的標題有些太聳動了。但,這是個媒體的時代,是吧! 讓我也來寫一篇
TurboChage your UI by MadButterfly :-)
不過從某些角度來看。只修改 scheduler 就可以讓『某些』狀況情況變好,那也許是值得
的。基本上,favor interactive processes 本來就是 time-sharing scheduler
的目標。這個 patch 只是補上 Linux scheduler 原本沒有做好的事而己。
不知道現在嘴砲 end user behavior 的目的是什麼?
這裡不是一堆人或多或少都在 Desktop 上編東西嗎?:-p
(前面什麼 tty assignment 的行為就不回了)
-Rex
YC
On Nov 17, 8:36 pm, Yu-Chung Wang <w...@homescenario.com> wrote:
> 如果每個程式都只用一個 process/thread。則 Linux 原來的 scheduler 就應該可以
> 運作的很好了。問題在於有一些 "task" 會fork 一大堆的 process/thread。這時
> scheduler 會分配比多的時車給這個 "task"。造成了 GUI/browser 等單行程的程式
> 吃虧了。
>
> 那誰會用一大堆的 process 呢? 有幾種
> 1 Server,如 apache/SMB/ftp
> 2 make -j xxx
> 3 某些支援 multi thread 的程式。
>
> (1) 是比較可能的狀況。對於跑 server 的機器而言,這個 patch 應該會很有效。因為
> 20 個 httpd 會分到和 browser 一樣的時間。而不是 apache 分到 20/21 而 browser
> 只分到 1/21。
>
> 在 2010年11月17日下午5:40,Thinker K.F. Li <thin...@codemud.net> 寫道:
>
>
>
>
>
>
>
> > 昨天晚上我有看過那兩百行,我覺的太 heuristic 了。基本上是用 tty 把所有
> > 的 task 分 group,然後再作 schedule。這樣的好處是確把每個 group 之間可
> > 以比較公平的分配 CPU time。問題來了,如果有一個 shell,不論 text 或
> > GUI 把所有的 task 都集中在一個 tty,或者反過來,每個 task 都配一個 tty。
> > 那麼情況又會回到原來的狀況。而, make -j n 這種把多個 heavy loading 的
> > task 集中在同一個 tty 的情況是特例。怎麼說? 因為一般人是不會 make -j n
> > 的,大部分人都是 apt-get 或用 GUI 安裝 binary。更常的狀況是一面開播音
> > 樂,一邊壓影片等多個 heavy load 的工作,而這些都不會 attach 額外的 tty。
> > 而且這些 GUI 軟體通常最多只有一個 CPU bound 的 thread。
>
> > 因此,這個 patch 是特別為 programmer 設計的 :D 對一般人沒有什麼效果。
>
> > From: Yuren Ju <yure...@gmail.com>
> > Subject: Re: sched: automated per tty task groups
> > Date: Wed, 17 Nov 2010 11:39:21 +0800
>
> >> 兩百行真的太強了
>
> >> 2010/11/17 Rex Tsai <chihc...@kalug.linux.org.tw>
>
> >>> FYI, it's awesome 200 line patch for linux kernel
>
> >>>http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&n...
> >>>http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&n...
>
> >>> Let's try it on your desktop machine.
>
> >>> Regards
> >>> -Rex
>
> >>> --
> >>> To post to this group, send email to
> >>> hacking...@googlegroups.com
> >>> To unsubscribe from this group, send email to
> >>> hackingthursd...@googlegroups.com<hackingthursday%2Bunsubscribe@ googlegroups.com>
可以用 cgroup 設定
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
( via slashdot http://linux.slashdot.org/story/10/11/18/2246213/Alternative-To-the-200-Line-Linux-Kernel-Patch
)
2010/11/17 way <wayl...@gmail.com>:
--
Pofeng "informer" Lee, 李柏鋒, pofeng at gmail dot com
私認為是雞同鴨講。 :-)
原 freebsd mailing list 提問[1]跟想解決的命題[2]根本不同阿,
ULE scheduler 根本不管你有多少 threads, processes.
ULE 是看程式運作時間,用所謂 interact score 來算 priority.
執行期間 runtime 越長 (interact score) 分數越高,
interactive score 越高 priority 越低,回應時間越快。
FreeBSD priority 範圍是 0 到 255, 範圍是這樣
* Interrupt threads: 0 - 63
* Top half kernel threads: 64 - 127
* Realtime user threads: 128 - 159
* Time sharing user threads: 160 - 223
* Idle user threads: 224 - 255
Freebsd 中 preempt thresh 預設是 64, 意即所有程式誰比較「清醒」又佔
更高優先值 (preempt)。
這樣一來哪些很常睡覺等使用者輸入的 Desktop 就很吃虧,一直讓人先跑。
顯然 FreeBSD Users 很少是桌面使用者。;-)
systcl -w kern.sched.preempt_thread=224 或 FULL_PREEMPTION 的設定只是
公平的不要讓哪些高度計算或編譯器或 periodic tasks 佔著不放。
這只是回到比較「公平」scheduler 狀態,GUI Application priority 還是輸人。
priority / interactive score 計算方式請參考
ULE: A Modern Scheduler for FreeBSD by Jeff Roberson.[5]
或見 FreeBSd kernel, sys/kern/sched_ule.c[3] 與 sys/sys/priority.h[4]
上述理解如有錯誤,請以文件或程式碼指教。
[1] http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/05a39f816fd8acc6/32ae3b6687ceb9d4?#32ae3b6687ceb9d4
[2] http://lists.freebsd.org/pipermail/freebsd-performance/2010-November/004073.html
[3] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283;content-type=text%2Fx-cvsweb-markup
[4] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/priority.h?rev=1.4.10.1.4.1;content-type=text%2Fx-cvsweb-markup
[5] http://www.usenix.org/event/bsdcon03/tech/roberson.html
> 天佑 FreeBSD,還好沒人會叫人 shut up,才會產出這麼快樂又無負擔的
> solution。FreeBSD 萬歲! 同樣,昨晚也看到有人提出 cgroup 的解法,也恭禧
> Linux user 當同得到一個不用 dirty 的 solution。另外也要讚賞一下
> wayling ,看出 cgroup 的潛力。下次如果再積極一點,說不定會變成第一個提
> 供另一個選擇的人。
看現在的做法[6],如果你們覺得 insecure (所有 user 都可以亂改惡搞別人的
processes cgroup),以及如果沒開 shell (沒載入 rc file) 就沒有用,這樣算乾淨的話
....那我也沒話說阿。
[6] http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
-Rex
我覺得 security 的問題比較好解,cgroup 是用 virtual file system 做的。只要把 permission
做好就可以了。問題是,設定那些行程屬於那些類別實在不是一件很容易做的事。而且到
底有沒有需要把一件簡單的事搞的這麼複雜。這看起有點像我們這些搞 realtime scheduler
的人常做的事 :-)
所以用 TTY 算是一個簡單但對某些情況有效的方法。不過這只對從 terminal 執行的程式有
幫助。用 GUI 生成的行程都算是一個。當然這也不見得有錯。
所以說,FreeBSD 不要高興,沒有 taskset 的概念,任何 OS 都是一樣的。
ULE 中的 preempt 機制不會讓 interactive 跟 CPU-intensive process
在一起的時候運作的更好。
調 threshold 只是改善被 CPU-intensive process 搶先的狀況。
而 "automated per tty task groups" 修的是 task set issue.
>> ULE 是看程式運作時間,用所謂 interact score 來算 priority.
>> 執行期間 runtime 越長 (interact score) 分數越高,
>> interactive score 越高 priority 越低,回應時間越快。
>>
>> Freebsd 中 preempt thresh 預設是 64, 意即所有程式誰比較「清醒」又佔
>> 更高優先值 (preempt)。
>>
>> 這樣一來哪些很常睡覺等使用者輸入的 Desktop 就很吃虧,一直讓人先跑。
>> 顯然 FreeBSD Users 很少是桌面使用者。;-)
>
> 下定論前,先看看 sched_wakeup() in
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283
>
> 下定論之前,也先看看
> crtical_exit() (注意 td_owepreempt)in
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_switch.c?rev=1.147
> mi_switch() in
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_synch.c?rev=1.320
> sched_add(), sched_shouldpreempt(), sched_switch(), sched_setpreempt() in
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283
>
>> priority / interactive score 計算方式請參考
>> ULE: A Modern Scheduler for FreeBSD by Jeff Roberson.[5]
>> 或見 FreeBSd kernel, sys/kern/sched_ule.c[3] 與 sys/sys/priority.h[4]
>
> 這些 paper 大多只是說一些概念性的內容,對於實作細節不會說的很清楚。如果
> 是質疑細節之前,最好先 RTFS。除非你很有自信。
我的確是讀過程式碼,所以才能引用原始碼說明。
歡迎說明這幾個函式如何計算 multi-process or multi-threads 的 priority.
Jeff Roberson 是 ULE 的主要開發者,如果你覺得他對於 ULE 理解沒有你清楚的話,
請指教論文中的錯誤或誤解。
Regards
-Rex
另外則是 userland utils 配置的問題,我頗懷疑這樣的設定環境,
而且真的能達到效果嗎?
這時就想起 SELinux 複雜的 policy 設定機制,Fedora 還預設開啟 SELinux,
造成終端使用者到處哀鴻遍野的慘叫聲
Regards
-Rex
順帶一提,Linux Kernel 則是對不同的使用情境,提供了不同的 Preemption 策略
CONFIG_PREEMPT_NONE: No Forced Preemption[1]
CONFIG_PREEMPT_TRACER: Preemption-off Latency Tracer[2] # 2.6.36 之後移掉了
CONFIG_PREEMPT_VOLUNTARY: Voluntary Kernel Preemption[3]
簡單講 Server 選 CONFIG_PREEMPT_NONE, Desktop 選 CONFIG_PREEMPT_VOLUNTARY.
[1] http://cateee.net/lkddb/web-lkddb/PREEMPT_NONE.html
[2] http://cateee.net/lkddb/web-lkddb/PREEMPT_TRACER.html
[3] http://cateee.net/lkddb/web-lkddb/PREEMPT_VOLUNTARY.html
-Rex
我想再多加幾個 CPU 好了。大家都不要吵了 :-)
> 這時就想起 SELinux 複雜的 policy 設定機制,Fedora 還預設開啟 SELinux,
> 造成終端使用者到處哀鴻遍野的慘叫聲
>
> Regards
> -Rex
>
> 在 2010年11月20日上午11:15,Thinker K.F. Li <thi...@codemud.net> 寫道:
>>> 原 freebsd mailing list 提問[1]跟想解決的命題[2]根本不同阿,
>>> ULE scheduler 根本不管�胃有多少 threads, processes.
>>
>> 我看不出�犠裡不同? [1] 和 [2] 都是為了讓 interactive process ,在和
>> CPU-intensive process 混合時,可以有更好的 response time。或是�胃看出什
>> 麼我沒看到的?
>
> ULE 中的 preempt 機制不會讓 interactive 跟 CPU-intensive process
> 在一起的時候運作的更好。
不會? 事實證明就是能改義 interactive process 的 response,而且我的
desktop 就是這樣設定。從 Code 的邏輯來看也是這樣。�胃要不要裝一台
FreeBSD 起來試試?
>
> 調 threshold 只是改善被 CPU-intensive process 搶先的瀲況。
>
> 而 "automated per tty task groups" 修的是 task set issue.
So what? 不是解決同樣的問題? 而且,如果�胃回去看 Kanru 所貼那一段文章,
就知道這個 patch 本來就只是想解決那樣特定的 scenario。或是�胃要質疑這樣
的設定無法解決該 patch 原來要改善的 scenario?
>
>>> ULE 是看程式運作時間,用所謂 interact score 來算 priority.
>>> 執行期間 runtime 越長 (interact score) 分數越高,
>>> interactive score 越高 priority 越低,回應時間越快。
>>>
>>> Freebsd 中 preempt thresh 預設是 64, 意即所有程式誰比較「清醒」又�壱
>>> 更高優先值 (preempt)。
>>>
>>> 這樣一來�犠些很常睡覺等使用者輸入的 Desktop �,A 就很吃虧,一直讓人先�煥。
>>> 顯然 FreeBSD Users 很少是�築面使用者。;-)
>>
>> 下定論前,先看看 sched_wakeup() in
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283
>>
sched_wakeup() 的 code 和 comment 都清楚的造訴�胃,那些常在 sleep 的
process/thread,會在 process/thread 重新回到 runnable 時,重新計算
priority。包括把休息這一段時間長短,也考慮進來。
所以�胃所珮的,明顯和 code 不符。
>> 下定論之前,也先看看
>> crtical_exit() (注意 td_owepreempt)in
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_switch.c?rev=1.147
>> mi_switch() in
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_synch.c?rev=1.320
>> sched_add(), sched_shouldpreempt(), sched_switch(), sched_setpreempt() in
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283
>>
這幾段 code 也很清楚的寫了,如果 priority value 如果小於
preempt_thresh, td_owepreempt 會設為 true。如果 td_owepreempt 為
true,該 thread 會立刻 preempt priority value 較大(低優先權)的 thread,
不會等目前的 thread 用完 time slice。這並不是變的比較公平,從某個角度來
看,反過是比較不公平,原本該是他的 time slice 被搶走了。但 response 改
善了,因為不用等那些 priority 用完他們原本分配的 time slice。
>>> priority / interactive score �,A 計算方式請參考
>>> ULE: A Modern Scheduler for FreeBSD by Jeff Roberson.[5]
>>> 或見 FreeBSd kernel, sys/kern/sched_ule.c[3] 與 sys/sys/priority.h[4]
>>
>> 這些 paper 大多只是珮一些概念性的勳容,對於實作細節不會珮的很清楚。如果
>> 是質疑細節之前,最好先 RTFS。除非�胃很有自信。
>
> 我的確是讀過程式碼,所以才能引用原始碼珮明。
> 歡迎珮明這幾個函式如何計算 multi-process or multi-threads 的 priority.
我已經把重點的 function 都貼出來了,如果�胃願意仔細一點,應該會了解。
>
> Jeff Roberson 是 ULE 的主要開發者,如果�胃覺得他對於 ULE 理解沒有�胃清楚的話,
> 請指教論文中的錯誤或誤解。
�0_這是斷章取義�休! 我什麼時侯珮他珮的有錯? �0_可以指出那一段我珮他有誤?
我是珮這類 paper 不會把所有細節都珮清楚。而誤解的是�胃,不是 Jeff
Roberson。
https://moodle.polymtl.ca/file.php/1093/Linix%20for%20RT.pdf
CONFIG_PREEMPT_NONE 基本上有關掉。
CONFIG_PREEMPT_VOLUNTARY: 則是打開。
簡單的說, preemption points 插的越多,latency 越低。不過 kernel overhead 越大。我
基本上認為一定要打開,因為 overhead 在現在的 CPU 來說實在太了。留個關掉的選項
不過是堵反對人的口而己。
在 2010年11月20日下午4:02,Rex Tsai <chih...@kalug.linux.org.tw> 寫道:
> 在 2010年11月20日下午3:34,Rex Tsai <chih...@kalug.linux.org.tw> 寫道:
>> 在 2010年11月20日上午11:15,Thinker K.F. Li <thi...@codemud.net> 寫道:
>>>> 原 freebsd mailing list 提問[1]跟想解決的命題[2]根本不同阿,
>>>> ULE scheduler 根本不管你有多少 threads, processes.
>>>
>>> 我看不出哪裡不同? [1] 和 [2] 都是為了讓 interactive process ,在和
>>> CPU-intensive process 混合時,可以有更好的 response time。或是你看出什
>>> 麼我沒看到的?
>>
>> ULE 中的 preempt 機制不會讓 interactive 跟 CPU-intensive process
>> 在一起的時候運作的更好。
>>
>> 調 threshold 只是改善被 CPU-intensive process 搶先的狀況。
>
> 順帶一提,Linux Kernel 則是對不同的使用情境,提供了不同的 Preemption 策略
>
> CONFIG_PREEMPT_NONE: No Forced Preemption[1]
> CONFIG_PREEMPT_TRACER: Preemption-off Latency Tracer[2] # 2.6.36 之後移掉了
> CONFIG_PREEMPT_VOLUNTARY: Voluntary Kernel Preemption[3]
>
> 簡單講 Server 選 CONFIG_PREEMPT_NONE, Desktop 選 CONFIG_PREEMPT_VOLUNTARY.
如上,這句話太誤導了。這些 latency 太低,基本上對 server 和 desktop 都不太有影響。
>
> [1] http://cateee.net/lkddb/web-lkddb/PREEMPT_NONE.html
> [2] http://cateee.net/lkddb/web-lkddb/PREEMPT_TRACER.html
> [3] http://cateee.net/lkddb/web-lkddb/PREEMPT_VOLUNTARY.html
>
> -Rex
>
我不太懂 FreeBSD 的 scheduler。不過先跳開 Linux/FreeBSD 不管。對原先要解決的問題
我們先做一個分析。原先的問題是,在一個系統中有 33 個行程,其中 32 個是 make,另
外一個則是 browser。怎麼樣才能讓 browser 的反應變快。
如果用完成 time sharing 的方法 schedule,那 browser最多 只能分到 1/33的時間。如果
render 一頁需要 100ms。那 browser 需要 3.3 秒才能 render 一頁。這顯然就會讓使用者
『感覺』系統很慢。
但如果我們把 browser 設成 realtime,這樣一頁就只需要 100ms 就可以 render 完了。使
用者一定會覺得系統很快。至於 make 完成的時間差個 1,2 秒應該沒差。
但是如果每一個人都想變 realtime,那就又回到原來的狀態了。所以最好每一個行程的優先
權還是讓 scheduler 來決定比較公平。問題是如何決定。
簡單的方法是讓 CPU 用太多的人以後少用一點。這應該就是 FreeBSD threshold 的意義。
不過如果 browser 和 make 都用了很多 CPU 時間,那效果應該就不大了。應該 scheduler
會認為二邊都用了太多時間而同步降低 priority。
這時候只有 task set 才能解決問題,將 32 個 make 行程看成是一個 process 來分配資源。
這樣 browser 可以在 200ms 完成工作。似乎是一個不錯的選擇。如果我沒記錯,Linux 的
scheduler 也有類似的設計。只是沒有參考可以調就是了。
不行,因為 browser 起來執亍了以後,因為用了 CPU priority 就會越來越大。如有
有一頁需要 100ms 完成,在有很多其它的行程存在的情況下。一開始的 50ms CPU
用的很娛快,但後面 50ms priority 變大了,CPU 就要和其它行程共用了。此外,即
使 priority 比較小,也不會一直被執行。它只是 time slice 分的比較多而己。否則就變
成 real-time scheduler 了。
>>>
>>> 調 threshold 只是改善被 CPU-intensive process 搶先的瀲況。
>>>
>>> 而 �,A "automated per tty task groups" 修的是 task set issue.
>>
>> So what? 不是解決同樣的問題? 而且,如果 胃回去看 Kanru 所貼那一段文章,
>> 就知道這個 patch 本來就只是想解決那樣特定的 scenario。或是 胃要質疑這樣
>> 的設定無法解決該 patch 原來要改善的 scenario?
>>
>
> 我不太�条 FreeBSD 的 scheduler。不過先跳開 Linux/FreeBSD 不管。對原先要解決的問題
> 我們先做一個分析。原先的問題是,在一個系統中有 33 個行程,其中 32 個是 make,�玩
> 外一個則是 browser。怎麼樣才能讓 browser 的反應變快。
>
> 如果用完成 time sharing 的方法 schedule,那 browser最多 只能分到 1/33的時間。如果
> render 一頁需要 100ms。那 browser 需要 3.3 秒才能 render 一頁。這顯然就會讓使用者
> 『感覺』系統很慢。
>
> 但如果我們把 browser 設成 realtime,這樣一頁就只需要 100ms 就可以 render 完了。使
> 用者一定會覺得系統很快。至於 make 完成的時間差個 1,2 秒應該沒差。
>
> 但是如果每一個人都想變 realtime,那就又回到原來的瀲態了。所以最好每一個行程的優先
> 權還是讓 scheduler 來決定比較公平。問題是如何決定。
>
> 簡單的方法是讓 CPU 用太多的人以後少用一點。這應該就是 FreeBSD threshold 的意義。
> 不過如果 browser 和 make 都用了很多 CPU 時間,那效果應該就不大了。應該 scheduler
> 會認為二邊都用了太多時間而同步降低 priority。
>
> 這時候只有 task set 才能解決問題,將 32 個 make 行程看成是一個 process 來分配資源。
> 這樣 browser 可以在 200ms 完成工作。似乎是一個不錯的選擇。如果我沒記錯,Linux 的
> scheduler 也有類似的設計。只是沒有參考可以調就是了。
>
我珮明一下 preempt_thresh 的義意。我們都知道 process 的 priority value
是動態調整,如果把 time slice 用的越滿, priority value 基本上就會愈
大,也就是 priority 愈低。而一般的情況,當系統在做 context switch 時,
會選一個 priority value 最小的 process 來執行。但,如果這個 process 在
執行當中,還未用完 time slice 之前,有�玩一個 priority value 更小的
process 變成 runnable 時,kernel 會怎麼做?通常是等目前的 process 用完
time slice 時,才會輪到該 process。而 preempt_thresh 是用來設定一個
threshold,當 priority value 小於該值時,該 process 不會等 priority
value 較大的 process,直接執行。所以平均能降低 1/2 time slice 的
response time。在 browser 這種 network IO+disk IO+CPU 重複 iteration 的
行為,這 1/2 time slice 的效果是 N * 1/2 time slice。也就是,如果
download 一個網頁需要 10 個 network IO 和 CPU burst,那就差 5 個 time
slice。在有 CPU-intensive process 搶 CPU 的情況,這通常意謂者 0.5 秒。
而調 preempt_thresh 之所以有效,就差在這 0.5 秒或更多。
然而, make -j N 這個 scenario 有一個情況,就是 gcc 和 sh 是不斷被重新
生。依傳統的設計,他們的 priority 一開始都是最低或較低的。因此還是會
有 browser 被 sh 或 gcc 搶走 CPU 的情況。在 FreeBSD 的處理方式是,
idprio 30 make -j N
這相當於把 process 的 nice 值調高,但效果更明顯。因為他的 priority 永遠
會大於 130,而一般的 process 永遠在 64~100 之間。這樣 make -j N 所 生
的 process 永遠都不會搶 browser 的 CPU time。而配合 preempt_thresh 的設
定, browser 卻能隨時把 gcc/sh 的 time slice 搶過來。這也就是為什麼這樣
的設定有效的主要原因。
YC
這就是為什麼像 tty group hack 或是 preempt threshold 這種有些 heuristic 的方法會受歡迎
的原因。你傻瓜它聰明嗎
YC
我想 Thinker 已經自己分析的很清楚了。
依照目前 ULE scheduler 的設定,interactive time 取決與 process sleep/runtime 比例。
process 越不活躍 (Ex: browser),priority value 越高,次序越慢。
如果 FreeBSD 使用者沒有改 default preempt threshold, Browser 可能還搶不贏一般的
daemon process.
Browser 一開起來,priority value 很低 (也就是 interactive processes),會很順暢,
開起來一段時間,priority value 跟著 sleep time 變高之後,使用自然會頓頓的,
除非你不停的讓 browser rendering 網頁,讓它保持持續運算 (interactive processes)的狀態。
這樣才能搶 gcc 的 cpu time.
-Rex
其實 automated per tty task groups patch 修的是目標是 responsiveness ?
而不是 scheduler 的排程演算法不是嗎 ? XD
但是 latency 越低換來就是 CPU throughput 也變低。
wycc 的意思是 preempt voluntary overhead 以目前 CPU 時脈的速度來講根本沒差?
所以高度運算的機器也應該用 CONFIG_PREEMPT_VOLUNTARY 嗎?
-Rex
if (need_reched) schedule();
對,CONFIG_PREEMPT_* 跟 FreeBSD 的 preempt_thresh 的目的不同。
-Rex
Phoronix 上有一篇用 2.6.32 作的 benchmark[1]
no forced preemption (CONFIG_PREEMPT_NONE)
只有用 GnuPG 加密, Writer performance 略勝。
[1] http://www.phoronix.com/scan.php?page=article&item=ubuntu_lucid_kernels&num=1
-Rex
其實分享 automated per tty task groups patch 是想改善 Desktop Responsiveness.
(我說是 Desktop Applicatoins, 需要即時多媒體處理哪種又是另外的需求)
要改善 Responsiveness, 會牽涉除了 scheduler 以外,比較重要的應該是 low latency,
I/O operations, 一些 system call 像是 waitpid, poll, futex 等等,
或者我們上週討論的 Graphics System - wayland. (事實上,後面這些好像影響更大)
在 scheduler 上,目前我們都是討論 CFS, 不知道是否有人玩過 BFS -
Brain Fuck Scheduler 呢 ? :-)
-Rex
low latency patch 則是採取另一個手段,它在核心中插入很多 preemption points。使得 kernel 在這些點上可以
被 preempt。理論上,只要點插的夠多,low latency 就會很低了。原先那個 _TRACE 選項就是用來收集可能需
要插入 preemption points 的地方。一般來說,preemption points 可能很容易的降低 latency。我記得以前我在做
的時候整個 kernel 只要插入少於 30 個點就可以把 latency 在 petium 233 的機器上降到 50us 以下。