twitter icon   twitter icon   rss icon

Linux.com Japan

Home 特集 Kernel Hackers Meeting Kernel Hackers Meeting

カーネルハッカーズ座談会 - Kernel3.0 & Linux20周年特集 -

1991年8月25日に産声を上げたLinuxは、 昨年で 20周年を迎えました。そして、カーネルのメジャーバージョンも3.0に更新。この2つの大きな節目を迎えたLinuxについて、日本を代表するコミュニティ開発者、Kernel Hackerの皆さんの集まって頂き、お話を伺いました。
終始笑いにつつまれた座談会の様子を、4回シリーズでお届けしています。

(編集部注:このインタビューは昨年(2011年)の夏に開催されたものです。時勢等はその当時のものであることをご了承下さい)


連載第1回】  連載第2回】  連載第3回】  連載第4回


杉田: 3.0で皆さんが提案した機能が入ったとか、嬉しいトピックスは何かありますか?


一同: チェックしていない。(爆笑)


亀澤:  自分の担当しているところで確実に入っているのは、バグを直したところですね。


フェルナンド:  IGMP snooping の修正パッチが入りましたね。それから、3.0に限らなくても良いならば、まだ入ってはいないけれど、入りそうな機能として、先程言っていた、ファイルシステム・フリーズ(fsfreeze)の改善版があります。整合性(consistency)の取れたストレージのスナップショットを取得したい時などに、ブロックデバイス(つまりディスク)上のファイルシステムを止めるために使う機能ですが、既存の機能には幾つかの根本的な問題があり、新方式を開発してメーリングリストに投稿しました。VFS のメンテナが忙しくてまだマージされていないのですが、幸運にも、Linux Plumbers Conference でこの問題について発表したら反響が良く、コードをレビューしてくれると言う別のメンテナが現れたので、近いうちに入りそうです。現場で使っていて色々問題があったので、今後はその心配がなくなると思う。


亀澤:  そういえば、iSCSIのスタックが何か変ったでしょ? その結果がどうなったか、誰か知っています?


フェルナンド:  スタックが変ったというか、iSCSI のターゲット(解説2)がカーネル内にも実装されました。従来のユーザ空間のターゲットと共存する形になっています。LIO (linuxiscsi.org) の Nicholas A.Bellingerが開発しました。

【解説2】 iSCSIターゲット
iSCSIはコマンドを発行し、処理を要求する「イニシエータ」と、その処理を行い、レスポンスを返す「ターゲット」で構成される。従来はユーザ空間でのみターゲット処理が行われていたが、現在はカーネル側でも一部が処理され、レスポンスの向上が図られている。


亀澤:  性能は良くなった?


フェルナンド:  ネットワークの特性によります。遅いと性能にそれほどの差が見られませんが、10GイーサネットやIB等の高性能ネットワークを使った環境だと、無駄なコンテキストスイッチが減る分レイテンシーが下がり、性能が上がります。実際に、2~3割くらいの性能向上を目にしたことがあります。


全員:  すごい!


平松:  仮想化分野でどう評価されているのかわかってないのですが、cleancacheがようやく入りました(解説3)。tmem(Transcendent Memory)の後継機能ですけど。これはどうです? 仮想化をやっている皆さんにとっては?

【解説3】 cleancache
cleancache は、「クリーン(ハードディスクなどと内容が同じ)なページ」をキャッシュするための機能。メモリが不足してきた時にクリーンな状態のページをこのcleancacheへと退避させてメモリを空ける。その後、実際のディスクにアクセスする代わりに、このcleancacheを見てそこに要求するページがあればそこから読み出す。これにより、ディスクに退避してそこにアクセスするよりも速いパフォーマンスを実現する、というもの。


亀澤: コントロールしにくいよね。


フェルナンド:  そうなんですよね。再現性がないので評価のしようがないっていうか。


亀澤:  frontswapなどのパッチも投稿されてきているから、Memory Cgroupのメーリングリストで、「帯域とか制限してテストして、性能を確認したりレビューしたりはしないの?」と聞いたのだけど、やらないって言われた。


山幡:  でも、Oracleが本気でやっているから、それなりに使えるものになっていくんじゃない?


フェルナンド:  使っているお客さんとかいます?


亀澤:  最初は使うかなと思ったけど、超エンタープライズシステムを使うお客さんは、この仕事は30分で終わると言ったら、29分で終わっても駄目だし、31分で終わっても駄目な仕事に使っている。だから早くなりますよと言われて、29分で終わってもあまり嬉しくない。だから使うのは難しいですね。使えればOK、処理は早ければうれしい、というお客さんは使ってくれるかもしれないけどなぁ。


山幡:  Xenでもこの機能は採用しているし、Oracle VMにも入っているはずだから、誰かが使っているとは思うけどね。


平松:  似たような機能で、KSM(Kernel Shared Memory:解説4)もあるじゃないですか、あればどうですか?

【解説4】 KSM(Kernel Shared Memory)
ハイパーバイザーで重複するメモリ・ページを 1 つに統合する機能。周期的にページをスキャンし、重複するページを特定してマージすることによって、ページを他の用途に使えるように解放する。重複するページがマージされた後に、そのページのユーザの 1 人が何らかの理由でページを変更した場合には、そのユーザ用に独自のコピーを作る (CoW 方式)。これらの動作は、ユーザにはわからないように行われる。また、これにより、同時に稼働する仮想マシンの数を増やすことができる。


フェルナンド: 仮想マシンの集約率が上がるという意味で素晴らしい機能ですが、検証に再現性がなく、KSMのカーネルスレッドが走り出すとCPU使用率が急に上がるとかで、「KSMが邪魔!」との声も。


山幡:  じゃあ、THP(transparent hugepage:解説5)も邪魔?

【解説5】 THP(transparent hugepage)
Linuxはpageという単位でメモリを管理しており、従来、1pageは4KB (4096バイト)だった。しかし、メモリの低価格化もあって数GB~数百GB搭載されるケースも多くなっており、これらを4KB単位で処理していると性能が低下する。この問題の対策の1つがTHP。hugepageはCPUに依存する機能であり、X86_64では、標準の4KB以外に、 2MB、1GBから選択が可能。


フェルナンド:  あ、それは使っています!


亀澤:  そういえば、THPで変な現象が起きることがあって、謎を知っていたら教えてほしいんだけど。姫野ベンチマークってあるじゃないですか。それを仮想マシン上で動かすとホストよりも早いスコアが出るんです。でも、THPをオフにするとちゃんとホストより遅いスコアで出る。これって、ベンチマークの中で全然違う判断をしていると思うのだけど、だけど、何が起きているのか、まだわかってない。


野村: ホスト側で走るときは THP が無効だけど、 KVM だと THP が有効になるからじゃないですか?


平松: THPって、ゲスト空間だけではなくて、ホストでも適用できますよね。ホストでもTHPをオンにしても駄目なのかな?


山幡:  それでも、結局、結果は運次第になるので、正確な評価はできないですよ。ということで、ある意味邪魔だということになる。


フェルナンド:  運次第という言う意味では、仮想化環境でゲストを動かすと、CPUが勝手にpower boost modeに切り替わって速くなる時がある。皆さんはそういう経験ある? 何回かそういうことがあって、コミュニティで議論したことがありました。


山幡:  逆に、遅い時は、power saveを切ってみてはどう? (一同笑い)


亀澤:  最近あった良いことというか、yield_toというのがあって、スピンロックを待っている方からスピンロックを持っている方にCPUを明け渡す機能なんだけど、KVMでも使えるようになったんだよね(解説6)。仮想マシンで複数CPUがあったときに、スピードアップできる。


フェルナンド:  KVMがスケジューラーにヒントを与えて実現する。

【解説6】 
ホストのスケジューラーは、yield_toを使ってKVM上の1つのVCPUのスレッドのプライオリティを上げることができる。運がよれば、そのVCPUがスピンロックを握っているVCPUであり、その処理を早く終了しロックを解放できる。ただし、今の実装では、KVMにはどのVCPUが
スピンロックを握っているか分からないため、効果は運次第と言わざるを得ない。paravirt spin lock が採用されれば追跡できるようになるため、コントロール可能になる予定。


杉田:  それは何かいいことがあるの?


亀澤:  仮想マシンのスケーラビリティが向上します。


平松:  busyloopが常に綺麗に適用できるからね。


フェルナンド: 無駄なルーピングを最小限にして運用できるという感じ。


亀澤:  まぁ、こんな風に細かく見ていくと、カーネル3.0にもいろいろ変更はあります。


(一同笑い)


フェルナンド:  話は変わるけど、Nick Pigginの VFS scalability のパッチセット(解説7)は読みづらいと思いませんか。結局、全部が採用されたけど、Dentryを管理するコードなど、カーネルの一番コアな部分にメスを入れているので、最初は使うのが怖かったですね。この件はLKMLでも話題になったけど、Linusはさらっとマージしちゃったよね。

【解説7】 VFS scalabilityのパッチセット
VFSレイヤーの従来の排他制御方式を RCU(Read-Copy-Update)方式に変えたパッチセット。RCUを採用することによって一部のオペレーションをロックレスにできるようになるが、dentryを管理するコードなど、カーネルの一番コアな部分を変更する必要があり、処理が非常に複雑になるため、大勢の主要開発者がマージに反対していた。


亀澤:  確かにトリッキーだし、あのパッチも怖い。でも、怖いけど、今のところちゃんと動いているんだよなぁ。


杉田:  怖いって、それはこれから障害が起こりそうな不安な部分があるとか? 


亀澤:  うーん。障害が起こるかどうかもわからない。例えるならば、自転車で綱渡りをしていて、今は全速力でこいでいるから落ちない、って感じかなぁ。


杉田:  なんか、その例えで雰囲気だけはわかりました。


(一同爆笑)


亀澤:  でもいいパッチですよ。すごく好きです。ここまでやっても良いのだということがわかったし。


杉田: つまり、チャレンジングなパッチなんですね。コミュニティの中でも「やってみようぜ」ってノリで採用されたの?


フェルナンド:  いやぁ、関連のサブシステムのメンテナ達がかなり消極的で反対していました。Nick Piggin 自身がとても慎重でカーネルに入れる前にもっとテストを行わなければならないと言っていました。スケーラビリティを実現するために、Linus の一存で入ったって感じかな。さらに困ったのは、Nick Pigginが投稿した直後、VFS scalability の取り組みから離れざるを得ない状況が起きた!


杉田:  その頃転職したよね? えっ、まさか彼はもうコミュニティに復活しないの?


一同:  いやぁ、どうかなぁ。いろいろ事情があるみたいですよ。


杉田: せっかく良いパッチを書いても、個人や会社の都合などで担当がいなくなることがありますよね。明確に誰かがその機能を引き継いでくれないと、メンテナンスされず、知らないうちにその機能がなくなっていくこともありますよね。今回の機能は大丈夫なの? 勢いで採用されていると聞くと、ちょっと不安。


亀澤: まぁ、メンテナがアフターケアをしていくから、何とかなりますよ。それに、よい機能や使える機能であれば、年月がたてば理解されて、皆がメンテナンスしてくれます。


平松:  RCU(解説8)もそうだったよね。

【解説8】 RCU
RCU(Read-Copy-Update)はスケーラビリティを支える構成要素の1つ。更新を「削除」と「再設定」のフェーズに分割し、削除フェーズを速やかに行い、削除フェーズに入ったときに動作していた全ての参照者が停止するまで再設定フェーズを遅らせる技法。RCUはデータ構造が複数のスレッドに共有されているときに使われ、特にそのデータがよく参照(リード)されて滅多に更新(アップデート)されない場合に有効。あるスレッドがそのデータ構造を読む場合、そのデータ構造を指すポインタを使用するため、ロックなどの操作は不要。


亀澤:  そうそう。今や猫も杓子もRCU!


(一同爆笑)


亀澤:  ところで、まだURCUの開発は続いているのかな?


平松:  続いているけど、緩~い感じ・・・・。


杉田:  他に、心に残っている機能とか、引っかかっている機能はありますか?


フェルナンド:  カーネル全体の感想ですけど、複雑になりすぎていて、心配しています。


平松:  そう。今までは周辺部分が頻繁に変わっていて、例えばファイルシステム内のコードはすごく複雑でややこしい状態になってきていた。それが今は、シンプルだったコア部分まですごく複雑になってきている。OSなのにMM(Memory Management)の下がよく変わるんだよね。なんか見るといつも変わっているから。ねぇ、亀澤さん。


亀澤:  僕だけの責任ではないですよ。それに今も Johannes Weiner 大先生が Memcg Naturalization(解説9)をバリバリ書いています。

【解説9】 Memcg Naturalization
memcg(memory cgroup)はcgroup用にメモリの使用上限を定める機能。現在はカーネルメモリ管理(MM)の追加機能であるが、Memcg Naturalizationは、memcgとMM機能とを統合し、mmにグループの概念を持たせ、memcgを使わない時でもmmは「グループが1つ存在した状態」として処理する仕組みを適用するパッチ。


杉田: ということは、またメモリ管理ががらっと変わる?


亀澤:  しょうがないですよ。MMはやはり、変わっていくものなんですよ、でも実は、そう言って自分を納得させているんですけど。


杉田:  それは使う側のニーズで変わるの? それともハードウェアの進化で変わるの?


亀澤:  うーん。今までも認識していた問題で、直すのをためらっていたけど、やっぱり、直そうよっていう話になることが多いかな。


杉田:  そうなの? 新しいハードが出たから直そうよってケースが多いと思ってた!


亀澤:  そう、違うんです。特にスケーラビリティ関連はね。THPなんかも、昔からやりたいという人は何人もいた。だけどいろいろな反対があって、なかなか実現できなかった。それをRed HatのAndrea Arcangeliが頑張って説得して入れた。


山幡:  でも、THPは積極的に認められた方だよね。


杉田: まだまだ実現できていない機能は多いみたいですね。でも、そういう裏事情を知ると、ドラマ要素も加わって、カーネル機能の変化の見方が変わる気がします。






To be continued… 
笑いが絶えない中、活発な議論が続きます。この続きはvol2で!
Kernel 3.0の内容の続きや組込み系のことなどに話題が広がります。お楽しみに!


続き(連載第2回)を読む




Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!