sched: automated per tty task groups
Rex Tsai
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=2
Let's try it on your desktop machine.
Regards
-Rex
Yuren Ju
--
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
CSJ
Yuren Ju
Kan-Ru Chen
% cat /proc/sys/kernel/sched_autogroup_enabled
1
測試把 kernel 重新用 -j4 重編 (我只有 2 個 core)，當 CPU loading 到
5.90 2.75 1.16
網頁還是很順，xterm 上的 irc 重繪也比以前順，所以應該是有用吧 :D
--
A badly written book is only a blunder. A bad translation of a good
book is a crime.
-- Gilbert Highet
CSJ
Thinker K.F. Li
的 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 <yur...@gmail.com>
Subject: Re: sched: automated per tty task groups
Date: Wed, 17 Nov 2010 11:39:21 +0800
> 兩百行真的太強了
>
>
> 2010/11/17 Rex Tsai <chih...@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&num=1
>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=2
>>
>> 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
Yu-Chung Wang
運作的很好了。問題在於有一些 "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。
Rex Tsai
這是一個很奇怪的假設，什麼系統或使用者有動機這麼做? 如果有人可以設計出給這種莫名需求都萬用的 scheduler，我倒是很想參拜。
Linus 對於類似意見的看法是 http://groups.google.com/group/linux.kernel/msg/fad388abcb364f55
;-)
Regards
-Rex
way
Rex Tsai
對 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
Thinker K.F. Li
> 如果每個程式都只用一個 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。
式也真的很少，一般 desktop 最常見的 multi-thread 程式就是 browser 本身
了。
Thinker K.F. Li
> 「如果有一個 shell，不論 text 或GUI 把所有的 task 都集中在一個 tty，或者反過來，每個 task 都配一個
> tty。那麼情況又會回到原來的狀況。」
>
> 這是一個很奇怪的假設，什麼系統或使用者有動機這麼做? 如果有人可以設計出給這種莫名需求都萬用的 scheduler，我倒是很想參拜。
的程式，看他們的 tty 都是指定成什麼樣。這基本上，一般使用者的環境就是這
樣，這是 desktop 的常態。
>
> Linus 對於類似意見的看法是
> http://groups.google.com/group/linux.kernel/msg/fad388abcb364f55
>
Linus 或許用的很爽，但改變不了這個 patch 對一般 end user 根本沒用的事實。
這個 patch 對 programmer 比較有用。試想，什麼時侯 server 上的 daemon 會
attach tty 了? 又什麼時侯 desktop 的 GUI 軟體有 attach 額外的 tty? 我並
不覺的這個 patch 完全沒用，但 programmer 而言，是很好的 patch。對一般
user 而言，基本上是一點作用也沒有。
如果大家回去看一下這個被測試的環境是什麼? 幾乎是 Open source project 的
programmer 才會有的環境。一般 user 有誰會開 terminal? 除了 programmer，
就是 server admin 吧! 但又有誰會 run make -j 4 之類的動作? 大概只有
programmer 吧。一般 user 常用的又是什麼app? 大概是 desktop 上的 app 吧。
而我們常見的 desktop APP 有 multi-thread 的程式又有多少?
再請各位仔細檢視一下自己的行為，除了 make -j N 之外，什麼時侯會在一個
tty 下執行多個 CPU bound 程式? 我不知道有多少人像我，只要開 terminal 一
定會 run screen，或都是開多個 terminal 的 tab。雖然 linus 本人很讚賞這
個 patch，但對我們的實際應用有多少效益?
Macpaul Lin
Yu-Chung Wang
multi-thread 程式太高的優先權。當然我們可以說，它對『一般人』沒有用。但至少也沒有壞處。
Server 通常也有管理 UI。這個 patch 對有 server 上的 browser 效能應該有幫助。另外
它對 BT 可能也有幫且哦 :-) 如果這個 BT 是用 multi-thread 寫的。
不過說實在的，這個報導的標題有些太聳動了。但，這是個媒體的時代，是吧! 讓我也來寫一篇
TurboChage your UI by MadButterfly :-)
Thinker K.F. Li
> hi all
> 我一直以為 cgroups不就已經解決了類似問題嗎? 奇怪了
生。而 Linux 最後的決策者是 Linus，他如果不爽/不喜歡某個 solution，不管
理由是多麼 OOXX，基本上就被淘汰。反之亦是。
Yu-Chung Wang
達到目的的做法。否則一個東西做好了，要等所有 distribution 都用才會成為 Linux
的一部份。而所有 distributions 又要等所有應用程式都支援了才能有完整的功能....
不過從某些角度來看。只修改 scheduler 就可以讓『某些』狀況情況變好，那也許是值得
的。基本上，favor interactive processes 本來就是 time-sharing scheduler
的目標。這個 patch 只是補上 Linux scheduler 原本沒有做好的事而己。
Kan-Ru Chen
> Linus 或許用的很爽，但改變不了這個 patch 對一般 end user 根本沒用的事實。
> 這個 patch 對 programmer 比較有用。試想，什麼時侯 server 上的 daemon 會
> attach tty 了? 又什麼時侯 desktop 的 GUI 軟體有 attach 額外的 tty? 我並
> 不覺的這個 patch 完全沒用，但 programmer 而言，是很好的 patch。對一般
> user 而言，基本上是一點作用也沒有。
Phoronix 的標題只是新聞效果 :P
Quote form patch:
> A recurring complaint from CFS users is that parallel kbuild has a negative
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> impact on desktop interactivity. This patch implements an idea from Linus,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> to automatically create task groups. This patch only implements Linus' per
> tty task group suggestion, and only for fair class tasks, but leaves the way
> open for enhancement.
Thinker K.F. Li
> "Thinker K.F. Li" <thi...@codemud.net> writes:
>
>> Linus 或許用的很爽，但改變不了這個 patch 對一般 end user 根本沒用的事實。
>> 這個 patch 對 programmer 比較有用。試想，什麼時侯 server 上的 daemon 會
>> attach tty 了? 又什麼時侯 desktop 的 GUI 軟體有 attach 額外的 tty? 我並
>> 不覺的這個 patch 完全沒用，但 programmer 而言，是很好的 patch。對一般
>> user 而言，基本上是一點作用也沒有。
>
> 這不是本來就這樣嗎？ 該 patch 從一開始就沒有說這是針對一般環境的改善，
> Phoronix 的標題只是新聞效果 :P
抱歉，我喜歡在興頭上澆一盆冷水。哈!哈!
>
> Quote form patch:
>> A recurring complaint from CFS users is that parallel kbuild has a negative
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> impact on desktop interactivity. This patch implements an idea from Linus,
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> to automatically create task groups. This patch only implements Linus' per
>> tty task group suggestion, and only for fair class tasks, but leaves the way
>> open for enhancement.
>
>
> --
> A badly written book is only a blunder. A bad translation of a good
> book is a crime.
> -- Gilbert Highet
>
Rex Tsai
> From: Kan-Ru Chen <ka...@kanru.info>
> Subject: Re: sched: automated per tty task groups
> Date: Thu, 18 Nov 2010 12:10:25 +0800
>
>> "Thinker K.F. Li" <thi...@codemud.net> writes:
>>
>>> Linus 或許用的很爽，但改變不了這個 patch 對一般 end user 根本沒用的事實。
>>> 這個 patch 對 programmer 比較有用。試想，什麼時侯 server 上的 daemon 會
>>> attach tty 了? 又什麼時侯 desktop 的 GUI 軟體有 attach 額外的 tty? 我並
>>> 不覺的這個 patch 完全沒用，但 programmer 而言，是很好的 patch。對一般
>>> user 而言，基本上是一點作用也沒有。
>>
>> 這不是本來就這樣嗎？ 該 patch 從一開始就沒有說這是針對一般環境的改善，
>> Phoronix 的標題只是新聞效果 :P
>
> 本來就是這樣沒錯。我也只是給過度興奮的人點出現實，所以本來也是這樣。
> 抱歉，我喜歡在興頭上澆一盆冷水。哈!哈!
不知道現在嘴砲 end user behavior 的目的是什麼？
這裡不是一堆人或多或少都在 Desktop 上編東西嗎？:-p
(前面什麼 tty assignment 的行為就不回了)
-Rex
Thinker K.F. Li
我誤會了嗎 ? :)
Yu-Chung Wang
mic
--
嘴炮也有好的啊 XD
Daniel Lin
Yu-Chung Wang
YC
c9s
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>
Yu-Chung Wang
李柏鋒 (Pofeng Lee)
可以用 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
Thinker K.F. Li
同樣在一陣嘴砲當中，如果你是 FreeBSD 的使用者，有人提議使用以下指令
systcl -w kern.sched.preempt_thread=224
就能在 FreeBSD 上，解決這個 Linux patch 所要改善的特定 scenario。這樣設
定有效的原因是， FreeBSD 的 scheduler (SCHED_ULE) 在 process/thread 的
priority 低於一定值時 (value 低，愈優先執行)，才會開始做 preempt
(preempt 別的 process)。而 make -j N 這種情況，通常會使 process 的
priority value 拉的很高。一般 interactive process 相對較低。因此，適當
的 preempt_thresh 使 make -j N process 和 interactive process 落在
preempt_thresh 兩端，可以讓 interactive process 隨時對 make -j N 或其它
CPU bound process 做 preempt，於是達到目的。
天佑 FreeBSD，還好沒人會叫人 shut up，才會產出這麼快樂又無負擔的
solution。FreeBSD 萬歲! 同樣，昨晚也看到有人提出 cgroup 的解法，也恭禧
Linux user 當同得到一個不用 dirty 的 solution。另外也要讚賞一下
wayling ，看出 cgroup 的潛力。下次如果再積極一點，說不定會變成第一個提
供另一個選擇的人。
Rex Tsai
> 關於這個 patch，昨天晚上也在 freebsd 的 mailing 上引起討論。
> 同樣在一陣嘴砲當中，如果你是 FreeBSD 的使用者，有人提議使用以下指令
>
> systcl -w kern.sched.preempt_thread=224
>
> 就能在 FreeBSD 上，解決這個 Linux patch 所要改善的特定 scenario。這樣設
> 定有效的原因是， FreeBSD 的 scheduler (SCHED_ULE) 在 process/thread 的
> priority 低於一定值時 (value 低，愈優先執行)，才會開始做 preempt
> (preempt 別的 process)。而 make -j N 這種情況，通常會使 process 的
> priority value 拉的很高。一般 interactive process 相對較低。因此，適當
> 的 preempt_thresh 使 make -j N process 和 interactive process 落在
> preempt_thresh 兩端，可以讓 interactive process 隨時對 make -j N 或其它
> CPU bound process 做 preempt，於是達到目的。
私認為是雞同鴨講。 :-)
原 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
Yu-Chung Wang
算是同一個 task。cgroup 其實就是提供一個方法讓 userspace 告訴 kernel 這件事。但
做法又有點另類，它要求行程自首。也就是說用行程要自己告訴 kernel 它屬性那一個
類別。然後 kernel 就可以用一個 hiearchical share driven scheduler 來分配所有的 resource。
我覺得 security 的問題比較好解，cgroup 是用 virtual file system 做的。只要把 permission
做好就可以了。問題是，設定那些行程屬於那些類別實在不是一件很容易做的事。而且到
底有沒有需要把一件簡單的事搞的這麼複雜。這看起有點像我們這些搞 realtime scheduler
的人常做的事 :-)
所以用 TTY 算是一個簡單但對某些情況有效的方法。不過這只對從 terminal 執行的程式有
幫助。用 GUI 生成的行程都算是一個。當然這也不見得有錯。
所以說，FreeBSD 不要高興，沒有 taskset 的概念，任何 OS 都是一樣的。
Thinker K.F. Li
> 在 2010年11月19日上午9:33，Thinker K.F. Li <thi...@codemud.net> 寫道：
>> 關於這個 patch，昨天晚上也在 freebsd 的 mailing 上引起討論。
>> 同樣在一陣嘴砲當中，如果你是 FreeBSD 的使用者，有人提議使用以下指令
>>
>> systcl -w kern.sched.preempt_thread=224
>>
>> 就能在 FreeBSD 上，解決這個 Linux patch 所要改善的特定 scenario。這樣設
>> 定有效的原因是， FreeBSD 的 scheduler (SCHED_ULE) 在 process/thread 的
>> priority 低於一定值時 (value 低，愈優先執行)，才會開始做 preempt
>> (preempt 別的 process)。而 make -j N 這種情況，通常會使 process 的
>> priority value 拉的很高。一般 interactive process 相對較低。因此，適當
>> 的 preempt_thresh 使 make -j N process 和 interactive process 落在
>> preempt_thresh 兩端，可以讓 interactive process 隨時對 make -j N 或其它
>> CPU bound process 做 preempt，於是達到目的。
>
> 私認為是雞同鴨講。 :-)
>
> 原 freebsd mailing list 提問[1]跟想解決的命題[2]根本不同阿，
> ULE scheduler 根本不管你有多少 threads, processes.
CPU-intensive process 混合時，可以有更好的 response time。或是你看出什
麼我沒看到的?
>
> 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 很少是桌面使用者。;-)
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c?rev=1.283
>
> systcl -w kern.sched.preempt_thread=224 或 FULL_PREEMPTION 的設定只是
> 公平的不要讓哪些高度計算或編譯器或 periodic tasks 佔著不放。
>
> 這只是回到比較「公平」scheduler 狀態，GUI Application priority 還是輸人。
>
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]
是質疑細節之前，最好先 RTFS。除非你很有自信。
>
> 上述理解如有錯誤，請以文件或程式碼指教。
>
> [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) 就沒有用，這樣算乾淨的話
>
> ....那我也沒話說阿。
開 shell。而，會開 tty 的程式，通常也會執行 shell。但執行 shell 就不一
定有開 tty，例如常用的 system()。質疑沒開 shell 就沒有用之前，是不是先
考慮一下沒有開 tty 是否就有用?
>
> [6] http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
> -Rex
>
> --
> To post to this group, send email to
> hacking...@googlegroups.com
> To unsubscribe from this group, send email to
> hackingthursd...@googlegroups.com
Thinker K.F. Li
> 整個問題的根源在於 kernel，不管是 FreeBSD 或是 Linux。都不知道那幾個 process
> 算是同一個 task。cgroup 其實就是提供一個方法讓 userspace 告訴 kernel 這件事。但
> 做法又有點另類，它要求行程自首。也就是說用行程要自己告訴 kernel 它屬性那一個
> 類別。然後 kernel 就可以用一個 hiearchical share driven scheduler 來分配所有的 resource。
>
> 我覺得 security 的問題比較好解，cgroup 是用 virtual file system 做的。只要把 permission
> 做好就可以了。問題是，設定那些行程屬於那些類別實在不是一件很容易做的事。而且到
> 底有沒有需要把一件簡單的事搞的這麼複雜。這看起有點像我們這些搞 realtime scheduler
> 的人常做的事 :-)
>
>
> 所以用 TTY 算是一個簡單但對某些情況有效的方法。不過這只對從 terminal 執行的程式有
> 幫助。用 GUI 生成的行程都算是一個。當然這也不見得有錯。
>
> 所以說，FreeBSD 不要高興，沒有 taskset 的概念，任何 OS 都是一樣的。
的 scenario。針對特定的 scenario 是要在 kernel 裡解決，或是在 user
space 用工具解決，那就見仁見智的。
而我所說的幸運，不是指 FreeBSD 的設計比較好。而是討論時，只要不做人身攻
擊，不會有人叫你住嘴。
Rex Tsai
>> 原 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 搶先的狀況。
而 "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
Rex Tsai
> 整個問題的根源在於 kernel，不管是 FreeBSD 或是 Linux。都不知道那幾個 process
> 算是同一個 task。cgroup 其實就是提供一個方法讓 userspace 告訴 kernel 這件事。但
> 做法又有點另類，它要求行程自首。也就是說用行程要自己告訴 kernel 它屬性那一個
> 類別。然後 kernel 就可以用一個 hiearchical share driven scheduler 來分配所有的 resource。
>
> 我覺得 security 的問題比較好解，cgroup 是用 virtual file system 做的。只要把 permission
> 做好就可以了。問題是，設定那些行程屬於那些類別實在不是一件很容易做的事。而且到
> 底有沒有需要把一件簡單的事搞的這麼複雜。這看起有點像我們這些搞 realtime scheduler
> 的人常做的事 :-)
另外則是 userland utils 配置的問題，我頗懷疑這樣的設定環境，
而且真的能達到效果嗎?
這時就想起 SELinux 複雜的 policy 設定機制，Fedora 還預設開啟 SELinux，
造成終端使用者到處哀鴻遍野的慘叫聲
Regards
-Rex
Rex Tsai
> 在 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.
[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
Yu-Chung Wang
> 在 2010年11月20日上午12:58，Yu-Chung Wang <wy...@homescenario.com> 寫道：
>> 整個問題的根源在於 kernel，不管是 FreeBSD 或是 Linux。都不知道那幾個 process
>> 算是同一個 task。cgroup 其實就是提供一個方法讓 userspace 告訴 kernel 這件事。但
>> 做法又有點另類，它要求行程自首。也就是說用行程要自己告訴 kernel 它屬性那一個
>> 類別。然後 kernel 就可以用一個 hiearchical share driven scheduler 來分配所有的 resource。
>>
>> 我覺得 security 的問題比較好解，cgroup 是用 virtual file system 做的。只要把 permission
>> 做好就可以了。問題是，設定那些行程屬於那些類別實在不是一件很容易做的事。而且到
>> 底有沒有需要把一件簡單的事搞的這麼複雜。這看起有點像我們這些搞 realtime scheduler
>> 的人常做的事 :-)
>
> 另外則是 userland utils 配置的問題，我頗懷疑這樣的設定環境，
> 而且真的能達到效果嗎?
>
聽起來像是 research 的題目 :-) 怎麼做都會有人有意見的，然後功能越加越多。最後，連原作者都
不會用了....
我想再多加幾個 CPU 好了。大家都不要吵了 :-)
> 這時就想起 SELinux 複雜的 policy 設定機制，Fedora 還預設開啟 SELinux，
> 造成終端使用者到處哀鴻遍野的慘叫聲
>
> Regards
> -Rex
>
Thinker K.F. Li
Subject: Re: sched: automated per tty task groups
Date: Sat, 20 Nov 2010 15:34:50 +0800
> 在 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。
Yu-Chung Wang
就是在 Linux kernel 裡面放入一些 preemption points。有興趣的人可能 google 一下
low latency patch 或是看一下我 98 年寫的一篇論文
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
>
Thinker K.F. Li
> 在 2010年11月20日下午3:41，Rex Tsai <chih...@kalug.linux.org.tw> 寫道：
>>
>> 另外則是 userland utils 配置的問題，我頗懷疑這樣的設定環境，
>> 而且真的能達到效果嗎?
>>
> 我也這樣覺得，其實 Linus 和很多人的想法也類似。不過要找一個自動化的 task set 產生器。嗯，
> 聽起來像是 research 的題目 :-) 怎麼做都會有人有意見的，然後功能越加越多。最後，連原作者都
> 不會用了....
>
> 我想再多加幾個 CPU 好了。大家都不要吵了 :-)
永遠不嫌多。
Thinker K.F. Li
> 在 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 搶先的狀況。
>
> 而 "automated per tty task groups" 修的是 task set issue.
process 的 priority 會有比較小的 priority 值。在這種情況下，只要
interactive process wakeup 之後，馬上會搶走 CPU-intensive process 的
time slice。所以 interative process 永遠不會等 CPU-intensive process ，
立刻被執行，這樣無法改善 response time? 還請你解釋!
Yu-Chung Wang
>> 調 threshold 只是改善被 CPU-intensive process 搶先的瀲況。
>>
>> 而 "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 也有類似的設計。只是沒有參考可以調就是了。
Thinker K.F. Li
和 FreeBSD 的 preempt_thresh 的目的不同，不能混為一談。
Yu-Chung Wang
不行，因為 browser 起來執亍了以後，因為用了 CPU priority 就會越來越大。如有
有一頁需要 100ms 完成，在有很多其它的行程存在的情況下。一開始的 50ms CPU
用的很娛快，但後面 50ms priority 變大了，CPU 就要和其它行程共用了。此外，即
使 priority 比較小，也不會一直被執行。它只是 time slice 分的比較多而己。否則就變
成 real-time scheduler 了。
Yu-Chung Wang
hiarchical share-driven scheduler. 先把CPU 時間分組，如果被分配的時間沒有被用到，
則會按比例讓其它的行程使用。這樣 browser 雖然有 50% 的系統時間，但最終 make
應該會分到 90% 的 CPU 時間，因為 browser 常常在休息。
Thinker K.F. Li
Subject: Re: sched: automated per tty task groups
>>>
>>> 調 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 搶過來。這也就是為什麼這樣
的設定有效的主要原因。
Thinker K.F. Li
式，考慮到會 run make -j 64 的 CPU 速度，這應該不是問題。而且一個 page
通常是有許多個 CPU burst 和 IO burst 組成，因此 priority 的調整速度並不
會那麼快。我在我的 desktop 上測試時，一個 google search page (當然比較
簡單) 幾乎不會讓 browser 調整 priority。當然圖多的情況就不同了，像
yahoo home page 會跳到 7x，但 gcc 之類的，通常 priority value 會在 9x。
而我的機器只是 eeebox， make -j 64 的機器，應該就調的更少。
當然 task set 或 classify 才能完全解決這些問題，但以目前的現實設計和需
求，這樣的設定已經可用了。
Kan-Ru Chen
我覺得像 CFS, cgroups 也引入滿久了，就是缺乏給 desktop user 的設定工具才
會出現像這次 200~ line patch 一鳴驚人的情況。 CFS 與 cgroups 多了許多參數
可以調，但有多少人真的會去調？我頂多也只繼續用 nice 去調而已。
既然 CFS 號稱完全公平，那就一定會有 browser*1, make*32 去比，怎麼會公平
的疑問，引用 Documentation/scheduler/sched-design-CFS.txt:
(此為 2007 年引入的設計，commit 5cb350ba)
> 7. GROUP SCHEDULER EXTENSIONS TO CFS
>
> Normally, the scheduler operates on individual tasks and strives to
> provide fair CPU time to each task. Sometimes, it may be desirable to
> group tasks and provide fair CPU time to each such task group. For
> example, it may be desirable to first provide fair CPU time to each
> user on the system and then to each task belonging to a user.
>
[...]
> When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is
> created for each group created using the pseudo filesystem. See
> example steps below to create task groups and modify their CPU share
> using the "cgroups" pseudo filesystem.
>
> # mkdir /dev/cpuctl
> # mount -t cgroup -ocpu none /dev/cpuctl
> # cd /dev/cpuctl
>
> # mkdir multimedia # create "multimedia" group of tasks
> # mkdir browser # create "browser" group of tasks
>
> # #Configure the multimedia group to receive twice the CPU
> bandwidth
> # #that of browser group
>
> # echo 2048 > multimedia/cpu.shares
> # echo 1024 > browser/cpu.shares
>
> # firefox & # Launch firefox and move it to "browser" group
> # echo <firefox_pid> > browser/tasks
>
> # #Launch gmplayer (or your favourite movie player)
> # echo <movie_player_pid> > multimedia/tasks
私以為 Desktop 需要的只是簡單的像 BitTorrent 一樣可以調整 group 與
priority 的下拉式選單就夠了。
--
A badly written book is only a blunder. A bad translation of a good
book is a crime.
-- Gilbert Highet
Yu-Chung Wang
情況。不過有用有保佑。
YC
Yu-Chung Wang
會被迫了解什麼是 apache, udevd, hald-runner, gtk-window-decoratror,......，然後一個一個
用『簡單的下拉式選單』去定義。
這就是為什麼像 tty group hack 或是 preempt threshold 這種有些 heuristic 的方法會受歡迎
的原因。你傻瓜它聰明嗎
YC
Thinker K.F. Li
的角度來看很蠢，但真的 work。相同的，這些設定也是可以透過相同的方式進
行，雖然不是 100%，但至少對大部分的 desktop user work。
Thinker K.F. Li
或許可以整合這方面的設定。
Kan-Ru Chen
> 問題出在，Linux 裡面根本就沒有辦法定義那些行程是一個『應用程式』。所到時後使用者
> 會被迫了解什麼是 apache, udevd, hald-runner, gtk-window-decoratror,......，然後一個一個
> 用『簡單的下拉式選單』去定義。
distro 可以有『對大多數人合理』的預設值。我剛剛心中想的下拉式選單也不是
generic 的系統工具，而是與 DE 整合的利用 DE 所掌握的資訊列出正在執行的程
式，從 shell 去執行的可管不到。
> 這就是為什麼像 tty group hack 或是 preempt threshold 這種有些 heuristic 的方法會受歡迎
> 的原因。你傻瓜它聰明嗎
火熱罷了。
Kan-Ru Chen
> Yu-Chung Wang <wy...@homescenario.com> writes:
>
>> 問題出在，Linux 裡面根本就沒有辦法定義那些行程是一個『應用程式』。所到時後使用者
>> 會被迫了解什麼是 apache, udevd, hald-runner, gtk-window-decoratror,......，然後一個一個
>> 用『簡單的下拉式選單』去定義。
>
> 也許可以利用現有的 applications registry[1] ，如此一來至少 DE 或是
> distro 可以有『對大多數人合理』的預設值。我剛剛心中想的下拉式選單也不是
> generic 的系統工具，而是與 DE 整合的利用 DE 所掌握的資訊列出正在執行的程
> 式，從 shell 去執行的可管不到。
[1]: http://standards.freedesktop.org/desktop-entry-spec/latest/
Thinker K.F. Li
> Yu-Chung Wang <wy...@homescenario.com> writes:
>
>> 問題出在，Linux 裡面根本就沒有辦法定義那些行程是一個『應用程式』。所到時後使用者
>> 會被迫了解什麼是 apache, udevd, hald-runner, gtk-window-decoratror,......，然後一個一個
>> 用『簡單的下拉式選單』去定義。
>
> 也許可以利用現有的 applications registry[1] ，如此一來至少 DE 或是
> distro 可以有『對大多數人合理』的預設值。我剛剛心中想的下拉式選單也不是
> generic 的系統工具，而是與 DE 整合的利用 DE 所掌握的資訊列出正在執行的程
> 式，從 shell 去執行的可管不到。
>
>> 這就是為什麼像 tty group hack 或是 preempt threshold 這種有些 heuristic 的方法會受歡迎
>> 的原因。你傻瓜它聰明嗎
>
> 沒有說 heuristic 不好，僅僅想指出為何功能都在那裡放了 3 年直到最近才吵的
> 火熱罷了。
Thinker K.F. Li
> Kan-Ru Chen <ka...@kanru.info> writes:
>
>> Yu-Chung Wang <wy...@homescenario.com> writes:
>>
>>> 問題出在，Linux 裡面根本就沒有辦法定義那些行程是一個『應用程式』。所到時後使用者
>>> 會被迫了解什麼是 apache, udevd, hald-runner, gtk-window-decoratror,......，然後一個一個
>>> 用『簡單的下拉式選單』去定義。
>>
>> 也許可以利用現有的 applications registry[1] ，如此一來至少 DE 或是
>> distro 可以有『對大多數人合理』的預設值。我剛剛心中想的下拉式選單也不是
>> generic 的系統工具，而是與 DE 整合的利用 DE 所掌握的資訊列出正在執行的程
>> 式，從 shell 去執行的可管不到。
>
> 忘了附連結：
>
> [1]: http://standards.freedesktop.org/desktop-entry-spec/latest/
environment 執行的 :D 或許以後剪輯軟體比較成熟之後會有用。
Rex Tsai
>>>>> ULE 中的 preempt 機制不會讓 interactive 跟 CPU-intensive process
>>>>> 在一起的時候運作的更好。
>>>>> 調 threshold 只是改善被 CPU-intensive process 搶先的狀況。
>>>>
>>>> process 的 priority 會有比較小的 priority 值。在這種情況下，只要
>>>> interactive process wakeup 之後，馬上會搶走 CPU-intensive process 的
>>>> time slice。所以 interative process 永遠不會等 CPU-intensive process ，
>>>> 立刻被執行，這樣無法改善 response time? 還請你解釋!
>> 不行，因為 browser 起來執亍了以後，因為用了 CPU priority 就會越來越大。如有
>> 有一頁需要 100ms 完成，在有很多其它的行程存在的情況下。一開始的 50ms CPU
>> 用的很娛快，但後面 50ms priority 變大了，CPU 就要和其它行程共用了。此外，即
>> 使 priority 比較小，也不會一直被執行。它只是 time slice 分的比較多而己。否則就變
>> 成 real-time scheduler 了。
>>
>> 還是要 task set 才能保証 browser 可以分到 50% 的 CPU 時間。其實這就是一般所稱的
>> hiarchical share-driven scheduler. 先把CPU 時間分組，如果被分配的時間沒有被用到，
>> 則會按比例讓其它的行程使用。這樣 browser 雖然有 50% 的系統時間，但最終 make
>> 應該會分到 90% 的 CPU 時間，因為 browser 常常在休息。
>
> 這我知道，但我們的 scenario 是一堆 CPU bound 和一個 browser 之類的程
> 式，考慮到會 run make -j 64 的 CPU 速度，這應該不是問題。而且一個 page
> 通常是有許多個 CPU burst 和 IO burst 組成，因此 priority 的調整速度並不
> 會那麼快。我在我的 desktop 上測試時，一個 google search page (當然比較
> 簡單) 幾乎不會讓 browser 調整 priority。當然圖多的情況就不同了，像
> yahoo home page 會跳到 7x，但 gcc 之類的，通常 priority value 會在 9x。
> 而我的機器只是 eeebox， make -j 64 的機器，應該就調的更少。
>
> 當然 task set 或 classify 才能完全解決這些問題，但以目前的現實設計和需
> 求，這樣的設定已經可用了。
我想 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
Rex Tsai
> 這個選項可能不是你想像的那樣。它是和 low latency patch 有關，low latency patch
> 就是在 Linux kernel 裡面放入一些 preemption points。有興趣的人可能 google 一下
> low latency patch 或是看一下我 98 年寫的一篇論文
>
> https://moodle.polymtl.ca/file.php/1093/Linix%20for%20RT.pdf
>
> CONFIG_PREEMPT_NONE 基本上有關掉。
> CONFIG_PREEMPT_VOLUNTARY: 則是打開。
>
> 簡單的說， preemption points 插的越多，latency 越低。不過 kernel overhead 越大。我
> 基本上認為一定要打開，因為 overhead 在現在的 CPU 來說實在太了。留個關掉的選項
> 不過是堵反對人的口而己。
其實 automated per tty task groups patch 修的是目標是 responsiveness ?
而不是 scheduler 的排程演算法不是嗎 ? XD
但是 latency 越低換來就是 CPU throughput 也變低。
wycc 的意思是 preempt voluntary overhead 以目前 CPU 時脈的速度來講根本沒差？
所以高度運算的機器也應該用 CONFIG_PREEMPT_VOLUNTARY 嗎?
-Rex
Yu-Chung Wang
> 在 2010年11月20日下午4:20，Yu-Chung Wang <wy...@homescenario.com> 寫道：
>> 這個選項可能不是你想像的那樣。它是和 low latency patch 有關，low latency patch
>> 就是在 Linux kernel 裡面放入一些 preemption points。有興趣的人可能 google 一下
>> low latency patch 或是看一下我 98 年寫的一篇論文
>>
>> https://moodle.polymtl.ca/file.php/1093/Linix%20for%20RT.pdf
>>
>> CONFIG_PREEMPT_NONE 基本上有關掉。
>> CONFIG_PREEMPT_VOLUNTARY: 則是打開。
>>
>> 簡單的說， preemption points 插的越多，latency 越低。不過 kernel overhead 越大。我
>> 基本上認為一定要打開，因為 overhead 在現在的 CPU 來說實在太了。留個關掉的選項
>> 不過是堵反對人的口而己。
>
> 其實 automated per tty task groups patch 修的是目標是 responsiveness ?
> 而不是 scheduler 的排程演算法不是嗎 ? XD
>
> 但是 latency 越低換來就是 CPU throughput 也變低。
> wycc 的意思是 preempt voluntary overhead 以目前 CPU 時脈的速度來講根本沒差？
> 所以高度運算的機器也應該用 CONFIG_PREEMPT_VOLUNTARY 嗎?
if (need_reched) schedule();
Rex Tsai
>> 順帶一提，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
>
> 這些主要是針對 kernel 的 preemption，對 application 之間切換的供獻不大。
> 和 FreeBSD 的 preempt_thresh 的目的不同，不能混為一談。
對，CONFIG_PREEMPT_* 跟 FreeBSD 的 preempt_thresh 的目的不同。
-Rex
Rex Tsai
>> 但是 latency 越低換來就是 CPU throughput 也變低。
>> wycc 的意思是 preempt voluntary overhead 以目前 CPU 時脈的速度來講根本沒差？
>> 所以高度運算的機器也應該用 CONFIG_PREEMPT_VOLUNTARY 嗎?
> 是的。打開這個選項只等打開一堆 premption check points。每一個 check points 大約等於下面的程式
>
> if (need_reched) schedule();
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
Rex Tsai
>> 在 2010年11月20日下午4:20，Yu-Chung Wang <wy...@homescenario.com> 寫道：
>>> 這個選項可能不是你想像的那樣。它是和 low latency patch 有關，low latency patch
>>> 就是在 Linux kernel 裡面放入一些 preemption points。有興趣的人可能 google 一下
>>> low latency patch 或是看一下我 98 年寫的一篇論文
>>>
>>> https://moodle.polymtl.ca/file.php/1093/Linix%20for%20RT.pdf
>>>
>>> CONFIG_PREEMPT_NONE 基本上有關掉。
>>> CONFIG_PREEMPT_VOLUNTARY: 則是打開。
>>>
>>> 簡單的說， preemption points 插的越多，latency 越低。不過 kernel overhead 越大。我
>>> 基本上認為一定要打開，因為 overhead 在現在的 CPU 來說實在太了。留個關掉的選項
>>> 不過是堵反對人的口而己。
>>
>> 其實 automated per tty task groups patch 修的是目標是 responsiveness ?
>> 而不是 scheduler 的排程演算法不是嗎 ? XD
> 不過 responsiveness 只能靠 scheduler 不是嗎?
其實分享 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
Yu-Chung Wang
在 Linux 中 有 SCHED_FIFO/SCHED_RR 等 realtime 優先權。但即使我們把一個 process 的優先權設成
SCHED_FIFO，它也不定能立即拿到CPU。原因在於 Linux 的 kernel 是否能被 preempt 的。早期的
Linux kernel 有 global lock，意思是說一但一個行程進入 kernel 模式後，在 system call 還沒完成前前其它的行程
是不能被執行的。現在的 kernel 有所請的 full preempt 模式。其實所謂的 full prempt 模式也不是隨時可以切換，
它只是把一個大 lock 分成一堆小 lock。當 kernel 不在這些小 lock 中時就可以被 preempt 了。
low latency patch 則是採取另一個手段，它在核心中插入很多 preemption points。使得 kernel 在這些點上可以
被 preempt。理論上，只要點插的夠多，low latency 就會很低了。原先那個 _TRACE 選項就是用來收集可能需
要插入 preemption points 的地方。一般來說，preemption points 可能很容易的降低 latency。我記得以前我在做
的時候整個 kernel 只要插入少於 30 個點就可以把 latency 在 petium 233 的機器上降到 50us 以下。
Kan-Ru Chen
> 在 scheduler 上，目前我們都是討論 CFS, 不知道是否有人玩過 BFS -
> Brain Fuck Scheduler 呢 ? :-)
就是因為疑惑 CFS 的齊頭式平等是否適合 Desktop 所以才換 BFS
不過我為了省電所以是用 CONFIG_HZ=300 ，可能不太準吧 :P