Linuxカーネルを高速化させた233行のパッチ 30
ストーリー by kazekiri
良いパッチ 部門より
良いパッチ 部門より
あるAnonymous Coward 曰く、
gihyo.jpにミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコードという記事が掲載されている。
とあるカーネルスケジューリングパッチがLinus Torvaldsを歓喜させたという記事である。このパッチはTTYごとにタスクグループを自動的に生成するもので、デスクトップ環境においてパフォーマンスが著しく向上し、Webページのローディング速度も向上するとのことらしい。記事では、2.6.38で取り込まれるとされている。
パッチに関しての議論は、Mike Galbraith氏が10月19日にLKMLへ投稿した[RFC/RFT PATCH] sched: automated per tty task groupsから続いており、11月14日にLinusが出したメールあたりが記事化されているようだ。
本家記事 (スコア:4, 興味深い)
The ~200 Line Linux Kernel Patch That Does Wonders [slashdot.org]と .bashrcいじくればいいだけでね? [slashdot.org]という記事も.
Re: (スコア:0)
なるほど．でもこういう機能は，ユーザ空間からではなくカーネル空間での担当だという考え方もありそうですし，
最初に気づいてアイデアを実装して見せている点では，非常にいい仕事していると思いました．
#まだ試していないのでこの発言もアレなのですが．
Re: (スコア:0)
他人のやったことを見て別のやり方を提示するのと、何もない所から高速化するのは後者の方が圧倒的に価値がある。
Re:本家記事 (スコア:2, 興味深い)
「.bashrcいじくれば」というくだりだけ読むと、カーネル空間をいじらずにユーザー空間の設定を変えるだけで同じ効果を出す方法であるかのような錯覚に陥りそうになりますが（というか自分は誤解した）、実際に読んでみると.bashrc経由でバリバリにカーネルオブジェクトをいじってるんですね。
具体的にはrootがカーネルオブジェクトを仮想ファイルシステム経由で書き込み権限つけてエクスポートして、それに対して各ユーザーが.bashrc経由でカーネルオブジェクトに自分のプロセス情報を突っ込むとか、かなり無理矢理で、実質的にはproof-of-conceptなんじゃないかと思います。
Re:本家記事 (スコア:2, 興味深い)
巨大な企業向けの機能で、シンプルさを重視する人たちから鬼子の様に邪険に扱われていた機能に、シンプルだが一般向けの用途が出てきたところに意義があるのでしょう。何せ、リソース管理ですから、新しいことをしようとすると、何かとcgroup関連の考慮が必要となるわけです。安易な修正のために、cgroup機能で問題になったことは、一度や二度ではない。
Re: (スコア:0)
あれのOSは、Linuxがベースになっていて、リソース管理のミドルウェアとの組み合わせで、スパコンとして運用できるようにしていたはずです。
Re: (スコア:0)
> 鬼子の様に邪険に扱われていた
ひのもとおにこですねわかります。
Re: (スコア:0)
へえ、今回のパッチは何もないところから高速化したんだ。
へえ、そうなんだ…
# そんなところで価値の優劣つけるなんておかしいんじゃね
Re: (スコア:0)
後出しじゃんけんに価値がないなんてことは元コメも言ってないぞ。
どちらの実装が優れているのかということとは別に、最初に実用出来るコードを書いたということは評価するべきだ。
これって (スコア:1)
窓でなくTTY単位になってるのが違うけどWindowsの「フォーカス持ってる窓に結び付いてるタスクの優先度が高くなる」って奴と同類？
Re:これって (スコア:1, 興味深い)
これまでのスケジューリングだと (A-1I)
(A-1E)
(B-F1)
(B-C1)
を同等に扱ってスケジューリングしてたけども、このパッチで
(A)(B)どっちのグループに割り合てるか決めて、それから、 (A)なら(A-1I)か(A-1E)
(B)なら(B-F1)か(B-C1)
というグループ化してスケジュール処理しようってことじゃない？
Re:これって (スコア:2, 興味深い)
それだと背後の再描画が高速化される理由を説明できないじゃん。動画は前面、画面、(カーネルビルドみたいに)画面と直接結び付いてない処理、のグループで優先度、この場合はプロセッサ割り当ての割合が違うように見えたけど。
どちらにしても、昔のカーネルみたいにスライス時間を消費するまでタスクが切り替わらないというわけではなくプロセッサをコキ使っていて、かつパッチ前のカーネルがタスク切り替えの時間がかかっていたというわけではないので、カーネルが高速化されたんじゃなくて体感速度が向上するように優先度を最適化して割り振っているのが鍵になってる筈。
Re:これって (スコア:4, 参考になる)
233 行しかないんで、詳しい人見てみてくださいね。sched_tty_sched_handlerのところがやりたいことらしいです。
Re: (スコア:0)
他のOSはどうなってるの？ (スコア:1, 興味深い)
Re:他のOSはどうなってるの？ (スコア:1, すばらしい洞察)
散々そう言われてきたじゃん。しかもまだ改善余地あるし(そっちは大改造になってLinusが嫌がるだろうけど)。
Re:他のOSはどうなってるの？ (スコア:2)
Windows2000以前では… (スコア:1)
WindowsXP以降で改善されたのかもですが、
DOS窓開いてformat a:を実行して、
他のウィンドウを前面に表示したら
背面にいったDOS窓の動作が止まってたと思います。
Re:Windows2000以前では… (スコア:1)
Windows2000だったと思うのですが、DOSプロンプトで何かの処理を実行中に右クリックすると処理中断(もう一度クリックしたら動作再開だったかな？)されるというのもありましたね。
Re: (スコア:0)
Re:他のOSはどうなってるの？ (スコア:2, 興味深い)
そうね、リアルタイムなんてのも、ごく最近になってマージされたしね。
正直、そこまでOSのパフォーマンスなんて要らない世界だったし、それに合わせて
アプリケーションを調整しなければいけない可能性が出てくるなら、あまり望ましくない。
今回の修正は、アプリの調整不要でのチューニングということで
価値があると思う。
Re: (スコア:0)
cgroup使ってない人なら特に無意味なのかな。
他のOSに比べてリソース管理だとかの核になる部分がころころ変わるから、
見逃されていた部分だったんでしょうねってだけかと。
Re: (スコア:0)
cgroupというと、富士通の亀澤氏のことを思い浮かべる。もっとも、亀澤氏の貢献は同じcgroupでも、CPUとMEMORY周りが中心だったようだが……。
伸びるということは、伸び代があるということ (スコア:0)
仰られる通り、「大きく伸びる」ということは「大きな改善の余地があった」という意味でもあります。
よく勘違いしている人が居ますが、これは改善者が優秀だったということでもありますが、それ以上に元が枯れてないという意味にもなります。
もちろん、改善者が天才で誰も思いつかなかったようなアプローチにて実現したとか、当時は不可能なアプローチが今では可能になったとか、そういうケースも多々ありますが、そういう事情を鑑みずに喜ぶのは平和ボケもいい所だと思います。
＃自分は平和ボケを通り越してただの馬鹿なのでAC
TTYとWEBアクセスに何の関係が？？ (スコア:1)
Re:TTYとWEBアクセスに何の関係が？？ (スコア:2, 興味深い)
Re: (スコア:0)
動画ではブラウザの背後でカーネルのコンパイルを100並列で行ったりしてるから関係あるんじゃないでしょうか。
とりあえず (スコア:0)
Re:とりあえず (スコア:1)
それだけだとググレないからちゃんと「57は素数」の人だってところまで書いてやれよ。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
3 を足せば 3 の倍数の 60 だし、5+7 = 12 -> 1+2 = 3 で 3の倍数とすぐに分かるはずだが・・・と思ったら、有名な数学者の間違いが元ネタなのね。