ユメのチカラ: Who wrote 2.6.20? 誰がlinux 2.6.20を書いたのか？
http://lwn.net/Articles/222773/ 先週のカーネル読書会でGreg KHがLinux Kernel開発コミュニティのお話をしていて、その中で開発の量的な側面についていろいろ紹介していた。そのスクリプトを眺めていたら、元ネタは、Jonathan Corbetという人が書いた「Who wrote 2.6.20」というLWNの記事ということをREADMEファイルから発見した。そこで早速Googleしてみた。それが上のリンク。 その記事はざっくり言うと、Linux Kernel 2.6.20を誰が開発し、その人はどこの会社に雇用されているかというのをgit(Linuxのコード管理システム)のログから定量的に解析したものである。 Linuxは多くのボランティアの自発的な貢献によって開発されていると良く言われているが、それがどのくらい正しいのか、そうでないのかを検証している
デバイスドライバロード時の動作 - や
どういう訳か、見えない「何か」に背中を押されたので、Linuxがデバイスドライバをロードした時の挙動を追ってみようと思います。例として(?) # modprobe r8169 した場合の挙動を追うことにします。 # 少し長めなので結論を急ぐ方は こちら をどうぞ。 まずは drivers/net/r8169.c の rtl8169_init_module() が呼ばれるところからスタートします。 static int __init rtl8169_init_module(void) { return pci_register_driver(&rtl8169_pci_driver); } static void __exit rtl8169_cleanup_module(void) { pci_unregister_driver(&rtl8169_pci_driver); } module_
「ディスク」への書き込み性能を上げるには - （ひ）メモ
ユーザランドのプロセスから見たwrite(2)は、ページキャッシュのおかげで(メモリが潤沢にある環境下では)ブロックされない(待たされない)というのは id:naoya さんの丁寧な解説のおかげでわかると思うのですが、一方、fsync(2)などの実際にディスクに書き込む処理、 あと id:hirose31 さんがコメントしてますが、アプリケーションが SYNC モードでファイルを開いてたり、明示的に fsync() してたりするとそこで wait が発生するのは言わずもがな、です。 Linux I/O のお話 write 編 - naoyaのはてなダイアリー The fsync() function does not return until the system has completed that action or until an error is detected. fsync
naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
Linux I/O のお話 write 編 - naoyaのはてなダイアリー
write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、本当にそうなんでしょうか？（否定しているわけではなく、純粋な疑問です。） と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネル本の 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
Vistaカーネルの内部 - Prex-組み込みリアルタイムOS開発日記
Mark Russinovichは、最近ではSonyのルートキットを見つけたとして有名になったが、カーネル・オタクの間では昔から有名だった。NTのサービスをフックするDDJの記事や、regmonやfilemonのソースコードはWindowsをハックする際にとても世話になった。彼のインタビュー・ビデオは以下。http://channel9.msdn.com/Showpost.aspx?postid=294410彼の書いた「Vista カーネルの内部」という記事が面白い。Windows Vista カーネルの内部 : 第 1 部Windows Vista カーネルの内部 : 第 2 部Windows Vista カーネルの内部 : 第 3 部ようやく全3部が揃ったみたいなので、興味のある点だけまとめておく。CPU サイクル カウント普通、スケジューラはTick毎にカレント・スレッドがそのTic
仮想デバイスドライバを利用したプロセス間通信について : tutorialog
仮想デバイスドライバを利用したプロセス間通信について September 11, 2006 Posted by butcher in : C, Operating System , trackback 仮想デバイスドライバを利用したプロセス間通信について説明します。といってもよくわからないと思うので、ちゃんと説明します。 Unixでプロセス間通信というと、ソケットを使ったもの、パイプを使ったもの、共有メモリを使ったもの等がありますが、それぞれ長所・短所があると思います。 ものすごく簡単に言うと、 ソケットでは、 複数マシン間での通信が可能 通信処理のオーバーヘッドが大きい(コネクション開始・終了処理も含め) パイプでは、 ソケットより通信処理のオーバーヘッドが少ない 親子関係のプロセスに限定される 共有メモリでは、 シンプルで高速 書き込み・読み取りの同期をとるのが難しい 等が
【コラム】コンピュータアーキテクチャの話 (6) キャッシュの構造(基礎編) - どういう単位でキャッシュに入れるのか? | エンタープライズ | マイコミジャーナル
キャッシュって何だろう? 性能の観点でCPUの仕様を見るとき、コア数、クロック周波数の次に来るのがキャッシュの容量というのが一般的であるが、キャッシュとはどういうもので、どう動くのかについてはあまり理解されていないように思われる。そこでこの一連の連載ではキャッシュについて述べようと思う。 プロセサのクロックが16MHz(GHzでは無い!)程度であった1980年代半ばまではDRAMメモリのアクセス時間も5サイクル程度であり、データをDRAMまで取りに行くことは大した問題では無かった。しかし、プロセサのクロックが1GHzを超えると、プロセサのクロック周期は1ns以下であるのに対して、DRAMのアクセスは1CPUの小規模システムでも50〜80ns程度であり、100CPUサイクルのオーダで待ち時間が発生することになった。これではプロセサコアはメモリにデータを取りに行く時間、遊んでいるばかりで、処理
プリエンプティブ・カーネル - Prex-組み込みリアルタイムOS開発日記
■[tech]プリエンプティブ・カーネル システムコール実行中にもインタラプトをトリガとして”即座に”スケジューリングが可能なカーネルをプリエンプティブ・カーネルと呼ぶ。 伝統的なUNIXカーネルでは、カーネルモード実行中にインタラプトが発生しても、その時点でスケジューラがキックされる事はない。カーネル実行中のスケジューリング要求は保留され、それはカーネルモードを抜けてユーザモードに戻る直前に処理される。このタイミングは要するに、カーネル内部の様々な”しがらみ”から開放されたユーザモードに近い状態であり、安全にスケジュールが可能である。カーネルモードであっても、例外やインタラプトによりカーネルの実行がネストする可能性があり、カーネルの出口ではどちらのモード（場所）に戻るのかを常に確認する必要がある。 このようなノンプリエンプティブな設計のカーネルでは、カーネル内部を実行するのは常にただ一つ
malloc The 67th kernel reading party - Google Video
The 67th kernel reading party - 1:39:31 - Sep 24, 2006 Yokohama Linux Users Group - www.ylug.jp/ () Rate: glibc malloc Download video - iPod/PSP | Embed video Download is starting. Save file to your computer. If the download does not start automatically, right-click this link and choose "Save As". How to get videos onto the iPod or PSP. <embed id="VideoPlayback" src="http://video.google.com/goog
4.4BSD オペレーティングシステムの設計と実装
4.4BSD カーネルは 4 つの基本機能を提供します。 それはプロセス、ファイルシステム、コミュニケーション、そしてシステムの起動です。 この節ではその 4 つの基本サービスのそれぞれについて この本で書かれていることを紹介します。 プロセスはアドレス空間上でのコントロールの流れを構成します。 生成や終了やその他のプロセスをコントロールするための仕組みは 4 章に述べます。システムは各プロセスの個別の仮想アドレス空間を 多重化します。このメモリ管理については 5 章で議論します。 ファイルシステムとデバイスへのユーザインタフェースは似ているため、 6 章ではそれらに共通する特徴について議論します。 7 章で説明するファイルシステムは、 ディレクトリが木構造になった階層で組織された名前付きのファイルと、 それらを扱うための操作からなります。 ファイルはディスクのような物理的なメディア上に存
tutorialog » 仮想デバイスドライバを利用したプロセス間通信について
仮想デバイスドライバを利用したプロセス間通信について September 11, 2006 Posted by butcher in : C, Operating System , trackback 仮想デバイスドライバを利用したプロセス間通信について説明します。といってもよくわからないと思うので、ちゃんと説明します。 Unixでプロセス間通信というと、ソケットを使ったもの、パイプを使ったもの、共有メモリを使ったもの等がありますが、それぞれ長所・短所があると思います。 ものすごく簡単に言うと、 ソケットでは、 複数マシン間での通信が可能 通信処理のオーバーヘッドが大きい(コネクション開始・終了処理も含め) パイプでは、 ソケットより通信処理のオーバーヘッドが少ない 親子関係のプロセスに限定される 共有メモリでは、 シンプルで高速 書き込み・読み取りの同期をとるのが難しい 等が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カーネルの再構築
Prex Kernel Internals
ビジュアルテクノロジー：技術コラム 第二十九回「キャッシュの動作イメージ」