元スレ【Linux】カーネル総合４【Kernel】

kernel覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

353 :

挫折おめ

354 :

Linux カーネルの設計図って無い？

ソースコードなんか読んでられないんだけど。

355 :

読むんじゃない　感じるんだ

356 :

設計図って無い？→×
ちょとソースパーサと視覚化ソフト作ってくる→〇

357 :

>>354
こんなものならある
http://www.makelinux.net/kernel_map

359 :

>>357
方向性は、いい感じ。でもちょっと詳細すぎる。
ソースコードを単純にリバースしただけ？
アーキテクチャの骨になるモジュールと依存関係が分かると入りやすいんだけどなぁ。

>>358
うーむ。ちょっと本屋にいってみまふ。

それ系だと、一応以下は読んでます。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080501/300463/?ST=oss

360 :

>>354
そもそも何がしたいわけ？

単に知りたいだけなら、本でもWebでもいろいろあるが、
将来的に開発に関わっていきたいなら、実装なんてころころ変わるから、
ソース読めるようになるしかないよ。

362 :

>>361

363 :

ソースは綺麗だがロックレスにするための最適化とかは難解じゃね

365 :

どうやってロックをなくすの？

367 :

変な改行してるけど、縦読みってわけでもないんだな。

368 :

CAS使ったって結局スピンループして待つわけだからロックと同じじゃなくて?

370 :

知る者が知らざるを者を罵倒する。これは日本人（固有）の得意技。

372 :

教えてもらったものが教えたものをひがむ
これこそ日本人固有の得意技

373 :

>>369,372
来なくていいから。お前の中身など何の価値もない。

374 :

>>368
locklessといっても実はいろいろあってな。
代表例をあげていく。

まず、時刻更新時のxtime更新処理。これは速度云々以前にタイマ割り込みの延長で走る更新処理が遅れちゃいけないという制約がある。時計狂いに直結するから。
だから、普通のread/write lockでは不十分で、「どれだけreaderがいても、writerは（待ったりスピンしたりせずに）即座に書き込めるロックが必要。
逆にreaderはwriterがごにょごにょやってるときは、多少処理が遅くなってもかまわない。だって時刻更新なんてせいぜい1000Hzでしかおきないレアイベントなんだもの。大局的には誤差。
詳細は、seqlockとかシーケンスロックでググってくれ。

次はRCU。
ようするに更新するときに、古いデータが載っているメモリを直接書き換えるのではなく新しいデータが載ったコピーを作る。
んで、read側は古いデータをちゃんと読めるのでロックいらず、write側がread側が知り得ない新しいコピーに書き込めるのでロックいらず。
というアイデア。
なんと、read側はCASもメモリバリアもいらないという最強アルゴリズムなのでlinuxでは適用箇所がガンガン広がっている。
もちろん、read側がクリティカルセクション抜けたときに（ガベコレ的な感覚で）あとから古いデータの削除処理が走るので、適用箇所によってはキャッシュヒット率の関係で性能が下がるときがまれにある。
まあ、readが大多数のデータ構造にしかつかうなってこった。

382 :

Linux Kernel Watch　9月版
　タイマにまつわるエトセトラ
http://www.atmarkit.co.jp/flinux/rensai/watch2008/watch09a.html
ある意味「予想どおり」のカーネルサミット
カーネル時間管理の全面刷新なるか
x86、「タイマを分かってないで賞」を受賞!?