@naota344の今週のLKML - Emacs ひきこもり生活

今週は

[PATCH 0/8] memcg async reclaim v2
[PATCH 00/12] staging: usbip
[PATCH 0/9] Optimize string operations by enhanced REP MOVSB/STOSB
Linux wireless support education video on YouTube
[PATCH 2/4] oom: kill younger process first

[PATCH 0/8] memcg async reclaim v2

http://permalink.gmane.org/gmane.linux.kernel.mm/63488

cgroupの一つにプロセスの実メモリ量(など)を制限するために使うことができる memcg というものがあります。

たとば、あるファイルをがんがん読みこむプロセスが500MBまでしかメモリを使えない、と制限をかけます。さて…どんどんメモリを使って読みこんでいってこれが500MBを超えようとした時点で…まぁ当然ながら一部メモリをswapしてやらなくてはいけません。そこで(500MBを超えようとした時点で)swapしてもいいページを探してswap outしてメモリを回収しにいきます。すると、「メモリ要求」->「超えてる」->「swap out処理」->「メモリ割当」という流れになってその間、メモリを要求していたプロセスは待っているほかありません。つまり、この分だけlatencyが悪化します。

さて、ではどうすればlatencyを良くできるでしょうか。

プロセスはだいたいメモリを要求してから、ファイル(やネットワーク)からデータを読みこむことが多い
時代はSMP

ということに注目しましょう。つまり、「プロセスがメモリを要求してからしばらくは次は要求しない」「その間に別のCPUがあいてる」ということです。すると、この空き時間と空きCPUを使ってasyncにメモリの回収をしておくことができるのではないか、というのが今回のパッチです。

具体的には、メモリ量が制限にある程度近付いてきたらasyncにメモリを回収するような「カーネルスレッド」を作成して走らせています。

パッチの提案で行なわれているテストケースを一部抜粋してみましょう。(あくまでも個人の意見にもとづいた抜粋なので注意) Apache Benchmarkを使ってHTTPサーバにアクセス、レスポンスが戻るまでの時間を計測しています。

B) limit to 300MB and disable async reclaim.

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:    29   35  35.6     31    3507
Waiting:       28   34  33.4     30    3506
Total:         30   35  35.6     31    3507

C) limit to 300MB and enable async reclaim.

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       2
Processing:    29   33   6.9     32     279
Waiting:       27   32   6.8     31     275
Total:         29   33   6.9     32     279

BでもCでもメモリ量を300MBに制限していますが、Bではasync reclaimがオフに、Cではオンになっています。平均で見ると大差はありませんが…max(一番時間のかかったケースの時間)を見ると3507msから279msとなかなかの改善を見せているように思います。

[PATCH 00/12] staging: usbip

http://permalink.gmane.org/gmane.linux.kernel/1143109

USB デバイスをIPネットワーク経由で共有するUSB/IP http://usbip.sourceforge.net/ を staging に追加するパッチが来ていました。リモートのUSBデバイスをローカルに刺さっているかのごとくに使えるようになるわけで…

USBストレージをfdiskしたりmkfsしたりmountしたりDVDを再生したり
USBキーボードとかマウスを使ったり
ウェブカメラやUSBのサウンドボードが使えたり
USBプリンタで印刷したり

ということが、リモートのものについてできる、という夢のような機能です。今から正式リリースに入る日が楽しみですね。

[PATCH 0/9] Optimize string operations by enhanced REP MOVSB/STOSB

http://permalink.gmane.org/gmane.linux.kernel/1141458

IntelのCPUがstring命令を最適化したのでそれを使おうぜ、というパッチがIntelの人から来ています。 copy_to_user/copy_from_user はユーザ空間と文字列をやりとりするさいに必ず使われるのでどうなるのかなかなか楽しみなパッチです。

Linux wireless support education video on YouTube

http://permalink.gmane.org/gmane.linux.kernel.wireless.general/70440

Linuxの無線LAN(802.11)サブシステムについての解説YouTubeの宣伝でした。802.11の概要・ドライバの書き方・デバッグ方法などが扱われています。

OOM Killer don't works at all if the system have >gigabytes memory / [PATCH 2/4] oom: kill younger process first

http://permalink.gmane.org/gmane.linux.kernel.mm/62793
http://permalink.gmane.org/gmane.linux.kernel.mm/62795

なんでも今のOOMのアルゴリズムは多くのメモリがあると、全てのプロセスのスコアが1になってしまいメモリが足りてない時にランダムにプロセスを殺してしまう危険なものになっているようです。

ということで、その対処の一部として「古いプロセスからではなく、新しいプロセスから殺していこう」というのが下のパッチです。

ほとんどの場合長く実行されているプロセスの方が新しいプロセスよりも大事なことをしている場合が多いわけです(デーモンとかデスクトップの管理とか)が、今の実装だと古いものから殺してしまって、大事なプロセスがいなくなって悲しいことになります。また、もう一つ新しいプロセスから殺していく利点には、終了しかけのプロセスを早く見つけられる、というものがあります。シェルスクリプトなんかでは大量に短い時間実行され終了するプロセスができるわけですが、OOMが発生した時に若いものから探すことで終了しかけのものをはやばやと回収することができて効率がいいわけです。