The Linux Foundation Japan Symposium #7

Linux

http://www.linux-foundation.jp/modules/eguide/event.php?eid=9
The Linux Foundation主催のシンポジウムに出てみたので、自分が気になった点のメモをアップしておく。自分の理解が間違っている点もあるかもしれないので、発表内容を知りたい方は、上記のサイトにある資料を見ていただきたい。テーマはBusiness Critical Linux。
なお、次回は7/9(水)、テーマは「セキュリティ」の予定らしい。そっちのほうが興味があるが、その時期は忙しいかも。

LF Driver Backports workgroup who, why, what --- Susanne Oberhauser (Novell)

最新のドライバのバックポートをどのように最新のカーネルに反映させるかという話。Driver Backportを一箇所でまとめる。これまではバックポートをユーザーが直接取り込んでいた。新しいシステムでは、バックポートをKernelやDistributionがSIに提供して、SI(system integrator)経由で届ける。bug fixも同様。この仕組みの細かいところはこれから定義しようとしている。

Q.アップストリームに入った修正をバックポートするか決めるのは誰か？
A.市場が決める。望む人がいればバックポートする。カーネルのメイン部に関わる修正である場合には、各ベンダ間で相談する必要がある。

質疑応答を聞いて･･･
日本で商用でLinuxを使用している人からは品質に関する懸念が大きいと感じた。また、責任の所在の明確化も必要。

Memory Management under Linux: Issues in VM Development --- Christoph Lameter(SGI)

メモリ管理の仕組みの簡単な説明。

マルチプロセス環境での同期管理も必要。Linuxのメモリ管理では未使用のメモリはない。ページキャッシュで使う。

昨年サポートされた機能

Anti-fragmentation logic
デバイス毎のdirtyページ管理
quicklists プロセスのページの起動時のキャッシュ
SLAB vs SLUB　旧システムではフラグメンテーションが残るので定期的に再起動をお願いしていた
Cgorup
Virtual Memmap

Q many coreサポートで、一部のcoreが壊れた場合などの可用性について考えているか
A コンポーネント毎にfall backする仕組みである

Q マルチプロセッサ時の一部プロセッサ障害時の動作
A 現状は一つが停止すればシステムが停止してしまう。インテル社なども認識している問題であり、相談中である。

Q なぜ従来のSLABでは問題が残るのか
A 誰も管理できないような問題が多々・・・

World Class High Availability using Linux-HA --- Alan Robertson(HA-Linux)

low availabilityのコンピュータを望んでいる人はいない。しかし、以下のような問題でhigh availabilityに取り組めていない。
　コストの問題 -> 昔に比べれば小さな問題
　複雑性
　標準性

split-brain・・・ネットワーク障害時などにそれぞれのノードが自分が生き残っていると認識してしまう状態
fencing・・・アクセスをガードする
quorum・・・split brainを防ぐ

single point failureを無くすようにHAコンポーネントを追加するという考え方。外部ネットワークの可用性はBGP,OSPFにまかせる。

データ共有の方法
　しない
　共有ディスク
　replicated data - disaster recovery DRBD
　back end server

Linux-HAは特別なハードは不要。カーネルにも依存しない。すべてユーザースペース。active/passive と active/active も可能。clone resource。virtual machinesをリソースとして管理できる。virtual machinesだからといって特別なことをするわけではない（start,stop...）

Horizonatal Scaling and its Implications for the Linux Networking --- David Miller(Red Hat)

ネットワークend to endの原則。良い例 DNS。悪い例 HTTP "how to kill the Internet" →改善のmodern example : Bittorernt

マルチキューデバイス
RXパケットのポーリングメカニズム New API -> NAPI

Q virtualizationでネットワークがやるべきこと
A 常に仮想化を意識して作業している...

Linuxにおけるリソース管理の改善 --- Satoshi Ohshima(Hitachi)

日本でのカーネル修正の現場の話。

  • coredump masking

core dump出力時に出力するメモリの領域をプロセス毎に指定できる機能。proc経由で設定。2.6.23以降でサポート。広大な共有メモリ領域を使用しているプロセスだと従来はcoreがでかくなってしまっていた。ulimit -cだと後ろが切れてしまう。スタック領域が切れてしまう。
他の対策法
　google-coredumper ユーザー空間でコアダンプするためのライブラリ
　 障害がおきたプロセス上で動作するので失敗する危険性がある
　ptraceを使ったコアダンプ　遅い
　core dump over pipe　コアダンプをパイプを通じて任意のコマンドに送る機能を使う。遅い。システムスローダウン

LKMLでのやりとり、F2Fでのやりとりによって仕様を決定。機能をカーネルで実現する必要性を明確に述べる必要がある。それぞれの提案の長所短所を整理する。反対する人がいてもあきらめない。メンテナが納得すれば採用されるのだから。テストはしっかりやる。

  • ネットワークメモリ管理の改善

悪意あるユーザーがroot権限なしに大量のカーネルページをピンダウンすることができる問題があった。UDPの受信キューにデータが滞留。Netdevにて議論。
小さいパッチにしたほうが採用される可能性が高い。様々な意見がもらえるので、早いうちにupstreamにパッチを投げてみるのが良い。まとまっていない状態でも。

パネル討議 'Experiences of Conference Participation' --- Tsugikazu Shibata (NEC), Christoph Lameter, David Miller

カンファレンスへの参加について。
海外のカンファレンスに参加するにあたり上司の理解を得ることが必要。アドバイスは？　協力関係を築く。非常に良いペーパーである場合には渡航の資金がもらえることもある。ペーパーを出せば会社の中でも説明がしやすく理解が得られやすいのではないか。英語で発表することに抵抗があれば、チームを作ってやるとよい。できれば国外の方も入れて。

2009年に日本でkernel summitを開催。日本からもSpeakerでぜひ参加してほしい。call-for-paper 2009/01〜03 に向けてがんばってほしい。

linuxカーネルとなると規模がでかいプロジェクトなので抜けがあるはず。まだまだやらなくてはならない仕事はある。興味がある（かぶる）プロジェクトがあれば連絡を取ってみるとよい。
メーリングリストでも、積極的にコミュニケーションを取るように。ネガティブな返信があっても反論するように。