WindowsVistaのソースコード！
面白すぎるだろこれ！
Open Innovation Business Model
LinuxCon Japan 2010でJim Zemlinのプレゼン「Ubiquitous Linux: The New Computing Fabric」のスライドに出てきた図が、オープンソースの経済的効果を説明するのに有用そうなので整理してみた。
説明していたコメントも要約して書き加えている。
Linuxなどのオープンソースが、ビジネスにどのような効果を与えるのかを簡単に説明できる。
- 開発コストは機器が複雑になり、爆発的に大きくなっている。イノベーションのためのコストが上がってきている。
- 最近は、携帯電話を平均14ヶ月しか使わないというデータがある。これはメーカーに対して大きな開発プレッシャーになっている。
- かつては、図の左側。開発コストに見合う収益を得ていた。
- いまのクローズドシステムは右側の図の状態。製品が複雑になり開発コストが肥大している上に、製品のライフサイクルが短くなり回収できる収益が減少してきている。
- Linuxはコラボレーションで製品をつくっている。高機能なOSや、IPスタック、汎用ライブラリのような部分はオープンソースプラットフォームとして共通化されてきている。
- 開発コストを節約するだけでなく、新しい収入源が得れる。Appstore、新しいサービスを作ることができる。これまでのクローズドなシステムではできなかったことだ。
- 新しい経済モデルができてきている。Androidの急速な普及がわかりやすい例。
「Open Innovation Business Model」は”Open Business Models: How To Thrive In The New Innovation Landscape”という本から引用している。
Open Business Models: How To Thrive In The New Innovation Landscape
- 作者: Henry Chesbrough
- 出版社/メーカー: Harvard Business Review Press
- 発売日: 2006/11/27
- メディア: ハードカバー
- クリック: 1回
- この商品を含むブログ (2件) を見る
Linuxがなぜこれほどまでに進化し続けているのか。
開発者なら直感的にわかるが、それ以外の人になかなかうまく伝えられない。
今年のLinuxConでもIBMのDan Fryeの説明を始め、説得力のある資料が出揃ってきたが、場面毎に最も効果のある材料を出せるようにしたい。
LinuxCon2010/Japanese Kernel Developer Panel
Japanese Kernel Developer Panel
パネリストの表記一覧
F: Fujita Tomonori, Research Engineer, NTT
K: Kamezawa Hiroyuki, Programmer, Fujitsu
H: Hiramatsu Masami, Researcher, Hitachi
Moderated by
J: Jon Corbet, Linux Weekly News
Q: 会場からの質問
パネルメモ
J:
コアカーネルの技術者は海外の方が多く思われていると思うのですが、
今回は日本の技術者で、世界的に知られているエンジニアに集まってもらいました。
パネリストの紹介
F：
藤田です。
SCSIなどストレージに関連する仕事をしてます。
K：
富士通の亀澤です。
メモリ管理の仕事をしてます。
H：
平松です。
トレーシング関連の仕事をしてます。
Kprobeの仕事をしてます。
カーネル開発をはじめたきっかけ
J：
どのようにカーネル開発に携わるようになったのでしょうか？
F：
2003年ごろに、iSCSIのサポートが仕事で必要になった。
やりはじめると、iSCSIとは関係のない部分もやるようになりました。
K：
2004年にはじめた。
仕事を探していて、カーネル開発ができると履歴書に書いていたら、
富士通でメモリホットプラグをやることになった。
メモリリソース管理cgroupを3年ほどやってる。
H：
大学でLinuxでロボット制御をやっていたが、
仕事ではじめたのは、2002年ごろからLKSTトレーシングプロジェクトから。
そのままトレーシング関連の仕事を続けています。
OSS開発に関わりたいと思っている人たちへのアドバイス
J：
OSSコミュニティで開発を始めたいという人へのアドバイスはありますか？
F：
自分がやりたいことを見つけるのが良いと思います。
カーネルハッカーになりたいというだけでは無理だと思います。
本当にやりたいことを見つけないと無理だと思います。
あと、パトロンがいる。
Linux開発ができる会社に入るとよい。
K：
LKMLを読むこと。
メールをきちっと読めば、Linuxカーネルのかなりの部分がわかるようになる。
一日800通のメールを1年も読めばね。
J：
ちょっと荒っぽいコメントですね！
Linuxメンテナの何人がLKMLを全部読んでるとは思えないですが・・・
J：
LKMLにもある程度のやり方があると思います。
人と関わるときに難しいことはありますか？
H：
参加はかんたんなのですが、RFCとか、手順がある。
メンテナが読んで、レスポンスを返すのですが、メンテナが休暇でなかなか返信してくれないときがある。こうしたカンファレンスはチャンスになる。
メンテナと直接話して、コミュニケーションをとれるので。
K：
こうした場に立つたびに、「メール送ります」とか言われるんですが、
日本人からの質問はその後来ないのです・・・。
LKMLを見てると、面白いテーマがあるはず。
関心があるテーマがあって、それが開発中だったら、とりあえず動かしてみると良い。
特に、patchのテストして結果を返すだけでも貢献できる。
J：
patchのテストはとても助かる。
信頼も得られる。
カーネル開発で難しかったことは？
Q： （by James Bottomley）
カーネル開発で難しかったことは何ですか？
F：
そんなに難しいことはなかったですよ。
SCSIはJamesがほとんどサポートしてくれましたし。
SCSIは小さなコミュニティなので、何でも相談できました。
カーネル開発ではそんなに困難はなかったですよ。
メンテナによっては苦労するかもしれませんが・・・。
K：
patchを書いてポスティングするのはそれほど難しくないですが。
この会場でメモリホットプラグがほしい人はどれぐらいいますか？
（パラパラと数人が手を挙げる・・・）
ほら、そこが難しいところなのですよ〜
H：
私はトレーサが専門で、変更範囲、量が非常に多い。
最初のpatchを送ったときに、3000行もあって、
メンテナがレビューもしてくれなかった。
LKMLのカルチャーを学ぶことだと思います。
カーネルで注目してる分野は？
J：
いまどんな取り組みをしているか。
今後、カーネルにどんな期待をしていますか？
F：
SCSIに関する面白いことがあるかを期待している。
K：
mem_cgroupをやってる。
メモリリソース制御に興味があるが、
今後、io_cgroup、コンテナ（接続性）に興味がある。
H：
Kprobeの取り組みをやっています。
perf probeがまだ終わっていません。
機能性の向上に取り組んで生きたい。
あと、MCEに興味がある。
これはCPUの機能です。
エラーをメモリの中で捉えるものです。
なぜ、オープンソース開発をするのでしょうか？
J：
なぜ、企業でオープンソース開発をやるのでしょうか？
世界中に公開されて、競合企業も使いますが。
H：
トレーシングは重要な部分です。
たとえば、銀行のサーバーにおいて問題が起きたとき、
その問題解決を急いでやる必要がある。
このときにトレーサがあれば簡単に解決できる。
トレーシングはツールに過ぎず、それを共有することができる。
しかし、サポートのクオリティは、そのツールを作った人、知ってる人についてくる。
企業にとっては大きなメリットになる。
K：
私の部署は、プロプライエタリなシステムを出していて、
上司は、そこに実装されていた機能の実装を求めてくる。
あとは、顧客の要望だ。
F：
顧客はLinuxを使っている。
Linuxにはストレージ関連の強化が必要だ。
だから、私はLinuxを開発してる。
オープンソースエンジニアの企業での評価は？
Q：
みなさん、大企業で働いている。
大企業は非常に保守的なことが多いが、OSS開発エンジニアは評価されているか？
F：
Linuxは主要プロダクトであり、
私の会社では適正に評価されていると思う。
H：
私も評価されていると思う。
LinuxがこれからのITシステムのインフラとみなされているので、
適正に仕事が評価されている。
K：
富士通は、日本のインフラを支える責任を担っている。
それは、Linuxをさしていて、エンジニアは評価されていると思う。
何のためにカーネル開発をやっているのか？
J：
Linuxを開発するのは、お金だけのためにやってるのではないです。
ブラジルで、こんな議論があった。
Andrew Mortonは人のためと答えました。
Linusは自分のためにやってると言っている。
しかし、Linus人のためになるのがうれしいと感じているからやってる。
結局、2人は同じことを言ってると思いました。
みなさんはどうでしょうか？
F：
Linuxには非常に才能のあるプログラマがいます。
そうした人たちと一緒に仕事をするのが楽しい。
K：
NASAでLinuxが使われている。
ということは、私の成果はNASAで使われている。
OSSの仕事は世界の役に立てる。
H：
藤田さんが言ったのと同じで、この業界には才能があっていい人がたくさんいる。
これはどんなエンジニアにとっても、良い経験になります。
みなさんも、是非参加してみてください！
日本人メンテナは登場するのか？
J：
さっき、パネルの人と話していて、
treeがたくさんあります。これがトップレベルのtreeにあげられる。
日本の人たちがトップレベルのtreeのメンテナになることは考えられますか？
F：
開かれてる状態と言ってもよいのではないでしょうか？
メンテナンスの重要な役割は誰かがやっていて、
J：
Jamesが他のことに興味があってSCSIメンテナをはずれるとしたら。
藤田さん、やりますか？
F：
できるならやりますよ！
H：
現行のものを修正するのが得意です。
すでにメンテナといえるのではないでしょうか。
いずれかは、新しいトレースツールが出てくるかもしれません。
いま、gitを使っているのは理由がある。
日本の企業ではgitのポートも通さない会社も多い。
内部と外部で2段階のレビューの仕組みがある。
それで、私はgitツリーを使っていない
Q：（by James Bottomley）
treeはたくさんあるし、メンテナは日々追加されているので、
その機会はたくさんあると思う。
F：
日本人がトップレベルのメンテナやっても問題ないと思います。
カーネルの開発は落ち着くことがあるのか？
J：
別のカーネルパネルで出てきた質問ですが、
いろんなシステムを取り込んでいくときに、開発速度が落ちてくると感じたことはありますか？
2005年に、AndrewMortonがpatchペースが落ちてきていると考え、
カーネルが完成に向かっていると予言したことがある。
しかし、そのあとも変更が落ち着く様子は無い。
F：
新しいデバイスが出てくる限りは続くでしょう。
SCSIだけを見ても、ファニーなデバイスが次々と出てくる。
SSDとか・・
これを対応し続けるのは、世界中の人にとって良いことだ。
K：
私も開発が終わることは無いだろうと考える。
1つは、スケーラビリティ。
1ソケット64コアのCPUが登場してくるらしい。
そうなってくると、もっと問題が出てくる。
現時点でのコードは、慎重に開発されているのでスケーラビリティが問題にならないかもしれない。しかし、いままでケアしてなかった部分でボトルネックが出てくるだろう。
H：
GPUやSSDはどんどん出てきている。
誰かが新しいデバイス、テクノロジーを使っていると、
新しい可能性を見つけるかもしれない。
また、新しいユーザー、新しい利用形態が見つかっていく。
ITシステムだけじゃなく、工場の制御システム、鉄道、交通
新しいフロンティアは常に存在し、直面していくので、カーネル開発の余地はあるだろう。
これからもLinuxは続くのか？
J：
これまでのコンピューティング産業を考えて、
Linuxが他のものに置きかわる可能性はあるでしょうか？
それとも、Linux Foreverか？
H：
新しいOSを作るのは非常に難しいと思うが、
たとえば、誰かが新しいOSを作るかもしれないが、
やはりそれはオープンソースだと思う。
K：
私が学生のときに一からOSを作った。
非常に開発が遅かった。
新しいOSもオープンソースになるのは確実だろう。
組み込み開発者を巻き込むには？
J：
日本には組み込みの開発者がたくさんいると思う。
会場に組み込みの開発者はいますか？
こうした人たちはあまり見かけませんが？
F：
理由は良くわかりませんが、組み込みの人たちには何か障害があるのだろう。
別の世界に住んでるように見えます。
前に比べると見かけるようになったが。
K：
先日、富士通エンベデッドシステムからメールを受け取った。
バックポートの相談だったが、6年間で初めてだった。
H：
組み込みの中では特別なコミュニティがある。
CELFとか。
メインストリームのコミュニティとは違う。
アップストリームのコミュニティに追いつこうという人もいる。
Linuxは制御系にも入っている。
最新版カーネルと、製品カーネルとのギャップ
Q：
実際に会社や製品で使われているカーネルと、現在開発されている最新カーネルとギャップを感じることが多いですが？
K：
いつも感じてますよ。
私のサポートしているシステムでもずいぶん古いカーネルを使っていることがあります。
ギャップもフィードバックをしてくれれば、改善されるかもしれない。
H：
たしかに、ギャップを感じる。
そうしたギャップを感じさせるのは、我々の課題かもしれない。
感じないようにするようにしなければならない。
これは、組み込みの人たちにとっても大事だと思います。
LinuxCon/How to Extract a Process Coredump Image From Crashdump
How to Extract a Process Coredump Image From Crashdump
Seigo Iguchi, NEC
背景
2003年からテレコム向けにLinuxをサポート
2.6.1xベースのCGL（x86-64）
2つの課題
（１）OS，HW
→Oops panic, Machine check error・・・
（２）ユーザーランドの問題
sysrq crushdump
/proc/sys/kernel/sysrqがシステムのリソース上限に達したときに呼ばれるときなど。
→これらの問題が起こったときに、顧客に何故起こったのかを説明しなければならない。
ここでは特に、ユーザーランドプロセスのvmcoreを説明する。
2.6.1x＋crah-3
- IBMの「lcrash」パッチを適応
crash-3
ELFを理解して、crash拡張のAPIを理解、coredumpの解析を行う。
linux-2.6.1xのELF coredump
elfdump main: fs/binfmt_elf.c:elf_core_dump()
問題
すべてのスレッド、メモリのデータを取れるわけではない。
shmemのデータは取れない。
dump()を変えるのも手か。
LinuxCon2010/Logging Kernel Messages Without a Loss
Logging Kernel Messages Without a Loss
Seiji Aguchi, Hitachi
概要
日立は政府系、金融系のシステム構築を行っている。
この業界では、Linuxの”RAS”が重要
- Realiability
- Availability
- Serviceability
無停止で安定して動くため、負荷のかからないロギング・メッセージ通知の仕組みが必要
syslog/klogd
syslogd/klogdは、メッセージをprintkバッファにいったん置いたあと、表示デバイスや、ネットデバイスに出力する。
しかし、カーネルがクラッシュしたら、このバッファが失われてしまう。
kmsg_dumperでこの問題に対策した。
panic,oops,kexecをトリガにする。
mtd_oopsドライバに、カーネルの出力バッファを吐き出す仕組みを入れた。
kmsg_dumperは、rebootとかシャットダウン、I/Oエラーには対応してない。
書き出し左記もMTDだけ。
Lockless kmsg_dumper
→crash_kexecをkmsg_dumperに備える。
将来的には、rebootなどでもバッファを拾い上げるようにしていきたい。
LinuxCon2010/Tuning Your Linux
Tuning Your Linux
Cai Fei, Fujitsu
Why tune
Linuxのディストリビューションデフォルトではいろんなシステムで動くようにしているので、最適化はされていない。
今回、チューニングしてみたらシステムのパフォーマンス（特にファイルI/O）で性能向上が見られたので、この手順を報告する。
Tuning principles
- Space for time
- キャッシュバッファを増やし、ループを減らす
- Safety for time
- ライトバックを減らす
- Decrease waste
- readhead削減
- Filter algorithm
- choose a fit I/O scheduler,filesystem
Tuning methods
- カーネルコンフィグ
- CONFIG_FUSION_MAX_SGE
- CONFIG_DEFAULT_IOSHED
- カーネルパラメータ
- /proc/sys/net/core/wmem_default
- /sys/block/sdx/queue/scheduler
- Command option
- mount -o commit=nrsec inode_readhead=n
- 不必要なサービスを止める
- auitd,smbd
- アプリケーション最適化
- setsockopt()
- マルチスレッドプログラミング
- プロセス優先度設定
- nice ionice
Tuning Process
- 問題の特定
- ボトルネックの特定
- パフォーマンスの測定
- 繰り返し
ツール
- ps & top
ex)
ps -eo pid,comm,nice.pri,sched,psr,pcpu,rss
- sar
システム全体のリソースモニタ
プロセスごとにCPU、メモリ、ネットワーク、swapの使用状況が見れる。
ボトルネック特定に役立つだろう
- iostat, vmstat, netstat & npstat
- strace & ltrace
システムコール、ライブラリコール
”-c”オプションをつけると、そのシステムコールが何回呼ばれたかがわかる。
ex)
strace -c ./pipe 5
パフォーマンスモニタ
関数ごとの実行時間のモニタ。カーネルバッファの使用状況も観測できる。
- Oprofile
CPUのボトルネックを特定するプロファイラ。（カーネル、ユーザースペース）
関数シンボル情報別のCPU使用率を出力できる。
- perf
パフォーマンスモニタ。
CPUイベントなどのハードレベル解析
ソフトウェアレベル解析
チューニング例
- 1GBのファイルだったら386MB/sでていたが、2GBんぼファイルになると241MB/sに落ちていた。
- sarとSystemTapで解析。
- iowaitのCPU負荷が1.5GB書き込みの後大きくなっていた。
- 誰がI/Oリクエストを出しているかを調査
→”flush”スレッドを特定
ここをチューニングし46〜51％向上した。
しかし、1GBのオーバーライト性能が悪いことに気づいた
（修正前後とも。もともとのあった新しい問題（問題２）。）
- オーバーライトが遅い問題
→sarで解析。
pdflushがネック
_set_page_dirty_nobuffers()をSystemTapでトレース
→73MB/s → 349MB/sに改善。
ext3だとnoauto_da_allocでマウントする。
他の例
- Safety for time
- mount -o commit=nsec /proc/sys/vm/dirty_expire_centisecs
- Decrese waste
- /proc/sys/vm/page-cruster
Tuning tips
- チューニング効果は、マシンの性能に依存する。
- チューニングの影響を考える。
LinuxCon/Multi-core Scalability on Modern Linux Kernels
Multi-core Scalability on Modern Linux Kernels
Andi Kleen, Intel Corporation
スケーラビリティとは
CPUやメモリを増やしていくことに対応すること。
より多くのスレッドを走らせることで可用性をあげるもので、リニアに性能があがるものではない。
Linuxサーバーはマルチコア、1TB以上のメモリを搭載するものがほとんどになった。
カーネルは大きなライブラリであり、データセットではない。
複数のユーザーが並行でこの処理を呼び、データ構造にアクセスする仕組みを提供するのが鍵になる。
スケーラビリティのdisadvantage
レイテンシ
複数CPUのデータシェアでは、参照カウンタをロックするので、ロック時にキャッシュラインがはずれ、パフォーマンスに影響する。
非常に処理コストが高い。
ネットワークシステムが代表的な例。
NUMAの問題
Code Lock vs Data Lock
最近のカーネルはコードロックは減らされてきている。
オブジェクトはネットワーク、SCSIホスト、ファイル・・
これらを並行して、効率よくキャッシュするように扱わなければならない。
Case study: global lock: dcache_lock
dcache_lockはグローバルロックを使う。
- dcache_lockのオーバーヘッド
- スレッド数にしたがってオーバーヘッドが増加する。
- dcache_lock とinode_lockを参照カウンタを減らすことで高速化させた。
ファイルシステム
DataIOはふつう、並行処理される。
しかし、複数のマウントポイントでうごかしてるとき、メタデータは複数のファイルシステムがそれぞれにロックする。
ディスクリプタごとにsyncしてしまい、ファイルシステムのパフォーマンスがアプリケーションに依存してしまう。
ext4はext3よりスケーラビリティが高い。
Extentsと新しいアルゴリズム
dataはO_DIRECTがベストだ。
ジャーナルスレッドがボトルネックになってるが、
近々、スケーラビリティに関する問題は修正されるだろう
XFS
XFSはスケーラビリティに関して、もっと良いロック機構をもつファイルシステムだ。
"allocation groups"で並行にアクセスできる。
並行にファイルを書き込むには有利になる。
large-I/Oで効果を発揮する。
btrfs
まだ開発中だ。まだスケーラビリティに関心がいってない。
ロックの問題がまだ残ってる。
Address spaces
Single lockでプロセスのアドレススペースを保護している。
mmap_sem
parallel page faults（並行でbrk/mmapを複数スレッドでやるとき）に問題が潜んでいる。
すべてのスレッドが単一のアドレススペースにヒットする
Workaround:
アプリケーションでmmaps/unmapsを減らす
