sched: automated per tty task groups

19 views
Skip to first unread message

Rex Tsai

unread,
Nov 16, 2010, 10:31:25 PM11/16/10
to hackingthursday, hacki...@groups.facebook.com
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

Yuren Ju

unread,
Nov 16, 2010, 10:39:21 PM11/16/10
to hacking...@googlegroups.com, hacki...@groups.facebook.com
兩百行真的太強了


2010/11/17 Rex Tsai <chih...@kalug.linux.org.tw>

--
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

unread,
Nov 16, 2010, 11:00:42 PM11/16/10
to hacking...@googlegroups.com, hacki...@groups.facebook.com
I applied attached patch on 2.6.37-rc2
But I did not see /proc/sys/kernel/sched_tty_sched_enabled
a.patch

CSJ

unread,
Nov 16, 2010, 11:02:00 PM11/16/10
to hacking...@googlegroups.com
oops, 附件版本錯了, a.patch 是給 2.6.36 用的
這一個附件 b.patch 我能成功打在 2.6.37-rc2 上面
b.patch

CSJ

unread,
Nov 16, 2010, 11:03:19 PM11/16/10
to hacking...@googlegroups.com
看來新版 patch 已經不用透過 /proc/sys/kernel/sched_tty_sched_enabled 來 enable 了

Yuren Ju

unread,
Nov 16, 2010, 11:40:05 PM11/16/10
to hacking...@googlegroups.com
有快到嗎?
CSJ 也來個 make -j 64 + 播 1080p 電影吧 XD

Kan-Ru Chen

unread,
Nov 17, 2010, 12:52:34 AM11/17/10
to hacking...@googlegroups.com
Yuren Ju <yur...@gmail.com> writes:

> 有快到嗎?
> CSJ 也來個 make -j 64 + 播 1080p 電影吧 XD
>

附上我用的 patch,打在今天的 HEAD 上,不用特別去 enable

% 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
0001-sched-automated-per-tty-task-groups.patch

CSJ

unread,
Nov 17, 2010, 1:06:40 AM11/17/10
to hacking...@googlegroups.com
嗯嗯  我也是感覺網頁的確有比較順,
但是在公司還沒辦法作進一步測試, 例如播放影片之類的

Thinker K.F. Li

unread,
Nov 17, 2010, 4:40:09 AM11/17/10
to hacking...@googlegroups.com, yur...@gmail.com, hacki...@groups.facebook.com
昨天晚上我有看過那兩百行,我覺的太 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 <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
>> hackingthursd...@googlegroups.com<hackingthursday%2Bunsu...@googlegroups.com>

Yu-Chung Wang

unread,
Nov 17, 2010, 7:36:21 AM11/17/10
to hacking...@googlegroups.com, yur...@gmail.com, hacki...@groups.facebook.com
如果每個程式都只用一個 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。

Rex Tsai

unread,
Nov 17, 2010, 7:38:11 AM11/17/10
to hacking...@googlegroups.com, yur...@gmail.com
「如果有一個 shell,不論 text 或GUI 把所有的 task 都集中在一個 tty,或者反過來,每個 task 都配一個 tty。那麼情況又會回到原來的狀況。」

這是一個很奇怪的假設,什麼系統或使用者有動機這麼做? 如果有人可以設計出給這種莫名需求都萬用的 scheduler,我倒是很想參拜。

Linus 對於類似意見的看法是 http://groups.google.com/group/linux.kernel/msg/fad388abcb364f55
 
;-)

Regards
-Rex

way

unread,
Nov 17, 2010, 7:59:48 AM11/17/10
to hacking...@googlegroups.com
hi all
我一直以為 cgroups不就已經解決了類似問題嗎? 奇怪了

Thinker K.F. Li <thi...@codemud.net> 於 2010年11月17日下午5:40 寫道:

Rex Tsai

unread,
Nov 17, 2010, 8:18:49 AM11/17/10
to hacking...@googlegroups.com
Hi, waylingii

對 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

unread,
Nov 17, 2010, 8:22:57 PM11/17/10
to hacking...@googlegroups.com, wy...@homescenario.com, yur...@gmail.com, hacki...@groups.facebook.com
From: Yu-Chung Wang <wy...@homescenario.com>
Subject: Re: sched: automated per tty task groups
Date: Wed, 17 Nov 2010 20:36:21 +0800

> 如果每個程式都只用一個 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。

說真的, server 真的很少會有 Desktop environment :D而 multi-thread 的程
式也真的很少,一般 desktop 最常見的 multi-thread 程式就是 browser 本身
了。

Thinker K.F. Li

unread,
Nov 17, 2010, 8:47:19 PM11/17/10
to hacking...@googlegroups.com, chih...@kalug.ks.edu.tw, yur...@gmail.com
From: Rex Tsai <chih...@kalug.ks.edu.tw>
Subject: Re: sched: automated per tty task groups
Date: Wed, 17 Nov 2010 20:38:11 +0800

> 「如果有一個 shell,不論 text 或GUI 把所有的 task 都集中在一個 tty,或者反過來,每個 task 都配一個
> tty。那麼情況又會回到原來的狀況。」
>
> 這是一個很奇怪的假設,什麼系統或使用者有動機這麼做? 如果有人可以設計出給這種莫名需求都萬用的 scheduler,我倒是很想參拜。

不會很奇怪,你去檢查一下所有你進 X 之後,不開 terminal emulator 所執行
的程式,看他們的 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,但對我們的實際應用有多少效益?
>> <hackingthursday%2Bunsu...@googlegroups.com<hackingthursday%252Buns...@googlegroups.com>

Macpaul Lin

unread,
Nov 17, 2010, 8:52:50 PM11/17/10
to hacking...@googlegroups.com
改善為促進工業革命而努力的工程師們的工作品質,
讓工程師更快更方便的產出更多有用的Code,就是改善一般User的效益。

Yu-Chung Wang

unread,
Nov 17, 2010, 9:00:18 PM11/17/10
to hacking...@googlegroups.com, chih...@kalug.ks.edu.tw, yur...@gmail.com
基本上,所有的 scheduler 的日策略,都是針對某一個特定的問題。Linux 現在問題是它給了
multi-thread 程式太高的優先權。當然我們可以說,它對『一般人』沒有用。但至少也沒有壞處。

Server 通常也有管理 UI。這個 patch 對有 server 上的 browser 效能應該有幫助。另外
它對 BT 可能也有幫且哦 :-) 如果這個 BT 是用 multi-thread 寫的。

不過說實在的,這個報導的標題有些太聳動了。但,這是個媒體的時代,是吧! 讓我也來寫一篇
TurboChage your UI by MadButterfly :-)

Thinker K.F. Li

unread,
Nov 17, 2010, 9:08:30 PM11/17/10
to hacking...@googlegroups.com, wayl...@gmail.com
From: way <wayl...@gmail.com>
Subject: Re: sched: automated per tty task groups
Date: Wed, 17 Nov 2010 20:59:48 +0800

> hi all
> 我一直以為 cgroups不就已經解決了類似問題嗎? 奇怪了

一個問題通常會有多個解決方案被提出來。有 cgroups 不妨礙其它解決方案的產
生。而 Linux 最後的決策者是 Linus,他如果不爽/不喜歡某個 solution,不管
理由是多麼 OOXX,基本上就被淘汰。反之亦是。
>> <hackingthursday%2Bunsu...@googlegroups.com<hackingthursday%252Buns...@googlegroups.com>

Yu-Chung Wang

unread,
Nov 17, 2010, 9:29:04 PM11/17/10
to hacking...@googlegroups.com, wayl...@gmail.com
從 Kernel developer 的角度來看,他們會比較喜歡一個不需要修改應用程式就可以
達到目的的做法。否則一個東西做好了,要等所有 distribution 都用才會成為 Linux
的一部份。而所有 distributions 又要等所有應用程式都支援了才能有完整的功能....

不過從某些角度來看。只修改 scheduler 就可以讓『某些』狀況情況變好,那也許是值得
的。基本上,favor interactive processes 本來就是 time-sharing scheduler
的目標。這個 patch 只是補上 Linux scheduler 原本沒有做好的事而己。

Kan-Ru Chen

unread,
Nov 17, 2010, 11:10:25 PM11/17/10
to hacking...@googlegroups.com
"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.

Thinker K.F. Li

unread,
Nov 17, 2010, 11:23:00 PM11/17/10
to hacking...@googlegroups.com, ka...@kanru.info
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

本來就是這樣沒錯。我也只是給過度興奮的人點出現實,所以本來也是這樣。
抱歉,我喜歡在興頭上澆一盆冷水。哈!哈!

>
> 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

unread,
Nov 18, 2010, 12:28:41 AM11/18/10
to hacking...@googlegroups.com, Thinker Li
在 2010年11月18日下午12:23,Thinker K.F. Li <thi...@codemud.net> 寫道:
> 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

unread,
Nov 18, 2010, 12:47:37 AM11/18/10
to hacking...@googlegroups.com, chih...@kalug.ks.edu.tw, thi...@codemud.net
From: Rex Tsai <chih...@kalug.ks.edu.tw>
Subject: Re: sched: automated per tty task groups
Date: Thu, 18 Nov 2010 13:28:41 +0800
這裡不準嘴砲嗎? 我覺的這次在嘴炮裡還含有知識成份,也算是 H4 的典範。
我誤會了嗎 ? :)

Yu-Chung Wang

unread,
Nov 18, 2010, 1:02:14 AM11/18/10
to hacking...@googlegroups.com, chih...@kalug.ks.edu.tw, thi...@codemud.net
唉! 你不曉得我們這些人一向不被當成是『user』嗎?

mic

unread,
Nov 18, 2010, 1:24:58 AM11/18/10
to hacking...@googlegroups.com
大家讓我長了知識....辛苦了.....:D
--
嘴炮也有好的啊 XD

Daniel Lin

unread,
Nov 18, 2010, 4:03:04 AM11/18/10
to hacking...@googlegroups.com
自從 Thinker 說「我昨晚看過那兩百行 code」我就感興趣起來了 :D

2010/11/18 mic <sinsmi...@gmail.com>



--
Daniel Lin (pct)

Yu-Chung Wang

unread,
Nov 18, 2010, 4:12:06 AM11/18/10
to hacking...@googlegroups.com
這可能是最近H4最熱鬧的 thread。証明一件事,『標題很重要』 :-) 難怪現在報紙越來越像八掛雜誌....

YC

c9s

unread,
Nov 18, 2010, 11:28:21 AM11/18/10
to HackingThursday
Chrome 算不算? Chrome 也 Fork 一大堆。

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

unread,
Nov 18, 2010, 6:56:23 PM11/18/10
to hacking...@googlegroups.com
一大堆在睡覺的 thread 是不算的.

李柏鋒 (Pofeng Lee)

unread,
Nov 18, 2010, 7:29:21 PM11/18/10
to hacking...@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

Thinker K.F. Li

unread,
Nov 18, 2010, 8:33:09 PM11/18/10
to hacking...@googlegroups.com, wy...@homescenario.com
關於這個 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,還好沒人會叫人 shut up,才會產出這麼快樂又無負擔的
solution。FreeBSD 萬歲! 同樣,昨晚也看到有人提出 cgroup 的解法,也恭禧
Linux user 當同得到一個不用 dirty 的 solution。另外也要讚賞一下
wayling ,看出 cgroup 的潛力。下次如果再積極一點,說不定會變成第一個提
供另一個選擇的人。

Rex Tsai

unread,
Nov 19, 2010, 11:05:59 AM11/19/10
to hacking...@googlegroups.com
在 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.

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

unread,
Nov 19, 2010, 11:58:33 AM11/19/10
to hacking...@googlegroups.com
整個問題的根源在於 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 都是一樣的。

Thinker K.F. Li

unread,
Nov 19, 2010, 10:15:12 PM11/19/10
to hacking...@googlegroups.com, chih...@kalug.ks.edu.tw
From: Rex Tsai <chih...@kalug.ks.edu.tw>
Subject: Re: sched: automated per tty task groups
Date: Sat, 20 Nov 2010 00:05:59 +0800

> 在 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.

我看不出哪裡不同? [1] 和 [2] 都是為了讓 interactive process ,在和
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 很少是桌面使用者。;-)

下定論前,先看看 sched_wakeup() in
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]

這些 paper 大多只是說一些概念性的內容,對於實作細節不會說的很清楚。如果
是質疑細節之前,最好先 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) 就沒有用,這樣算乾淨的話
>
> ....那我也沒話說阿。

如果你如果想想那個 patch,沒開 shell 哪來的 tty? 至少 90% 以上 tty 都會
開 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

unread,
Nov 19, 2010, 10:27:15 PM11/19/10
to hacking...@googlegroups.com, wy...@homescenario.com
From: Yu-Chung Wang <wy...@homescenario.com>
Subject: Re: sched: automated per tty task groups
Date: Sat, 20 Nov 2010 00:58:33 +0800

> 整個問題的根源在於 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 都是一樣的。

就像你所說的,和我前面提到的,這個解法和 tty group 的解法,都是針對特定
的 scenario。針對特定的 scenario 是要在 kernel 裡解決,或是在 user
space 用工具解決,那就見仁見智的。

而我所說的幸運,不是指 FreeBSD 的設計比較好。而是討論時,只要不做人身攻
擊,不會有人叫你住嘴。