Linuxカーネルのコードを読んで勉強になったこと - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルのコードを読んでて、なるほど〜と思うことはよくあるけど、その中でも特に今までの考え方をぶち壊してくれたのはなんだっけと思ったところ、やっぱりリスト構造かなと言うところ。 c言語でリスト構造を作る場合、一般的な教科書方式だと↓のようにデータとnextポインタは密結合になってると思います。これの場合、struct foobarのポインタをnext要素に使っているので、他の構造体（例えば、struct hogehoge）で同じことをしようとすると、その構造体ではstruct hogehoge *nextというメンバ変数を持つ必要があります。 ヘッド要素はstruct foobarです。 struct foobar { int n; char s[64]; struct foobar *next; }; struct foobar head; Linuxカーネルの場合、データとリ
glibcのmalloc(3)とLinuxカーネルのovercommitとOOM - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2015の23日目です。 glibcのmalloc(3)とLinuxカーネルのovercommitとOOMの関連でも見てみようと思います。Linuxカーネルのシステムコールにはmalloc(3)的なものはないので、mmap(2)、brk(2)が使われます。 今回知りたかったのは、どこでovercommitを許可しているのか？というところと、どのタイミングでOOMが発生するのかという2点です。 OOM発生時の挙動についてはsatoru_takeuchiさんの覚書(2015-12-03)に詳しく書かれていますので、こちらを参照してください。 glibcのmalloc(3)に関してはがちゃぴん先生のmalloc動画を見ましょう。 今回見ているglibcのバージョンは2.22でカーネルは4.3です。 まずはmalloc(3)の大まかな処理を見ま
Linux 4.0(x86_64)のメモリレイアウト - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2015の2日目の記事です。 今日は復習も兼ねてメモリレイアウトの確認です。 見るのはDocumentation/x86/x86_64/mm.txtです。見ているのは4.0ですが、4.3も同じでした。 で、メモリーマップですが下記のように説明されています。 6 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm 7 hole caused by [48:63] sign extension 8 ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved for hypervisor 9 ffff880000000000 - ffffc7ffffffffff (=6
Linux Kernel Hack入門編 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2014の25日目ですヽ(=´▽`=)ﾉ 今回はLinux Kernel Hack入門編ということで入門的なことを書いてみたいと思います。 まず使用する環境ですけど最近出たばっかのFedora 21のWorkstationにしました。まあ、今回の内容的にはディストリビューションは問わないんですが、多くの人が馴染んでいるであろうfedora系というかパッケージマネージャがyumということでこれにしてみました。 自分は普段Arch Linuxなんですけど、こっちだとkernelのmake install時にちょっとしたスクリプトを書く必要があったりするのもあって、fedoraのほうが手軽かなというのもあります。 カーネルコード・リーディング ブラウザベースでコード・リーディング 読めるソースは大概メインラインのカーネルということになりますが
Linuxカーネルで見る最適化の技 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2014の13日目です。 LWNのACCESS_ONCE() and compiler bugsを読んでなるほどねーと思ったのでその辺について書いてみたいと思います。 最適化の技と言いつつ実際は最適化させすぎない技なんですが＼(^o^)／ まずACCESS_ONCEマクロの役割ですが、これは必ずデータを読みたいという場合に使ってます。 例えばこんなコードがあったときに（かなり適当ですが雰囲気は掴めるはず） while (1) { struct foobar *p = foo; if (p->hoge) { .... } } コンパイラはこのように最適化をかけてくる可能性があるんだけど、fooは別のスレッドによって変更されるのでループ毎にデータをfetchして欲してというケースで使うのがACCESS_ONCEマクロみたいです。 struc
Linuxのpipeの実装を見てみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Unix V6のpipe()と比べてLinuxのpipe()どう実装しているんですかねーなんて話を最近したのでちょっと見比べてみた。 V6のpipeははじめてのOSコードリーディング 読書会 (15)でやったところなんだけど、俺は風邪ひいて家で引きこもってたので・・・ V6のpipeの挙動は大体こんな感じ。 pipeはルートディスクのストレージ領域を4096B（8ブロック）使用し実現する 4KBのデータ領域はひとつのファイルとして扱われる（inodeが割り当てられる） オンメモリではなくてストレージを経由するが、バッファサイズが小さいのでブロックデバイスのバッファキャッシュが効きやすいようになっている pipeの受け手がデータを読みだす前に他の優先度の高いプロセスがブロックデバイスを使用するとキャッシュが効かなくなる可能性あり でも、データはストレージに書かれているので内容が壊れると言った
Linuxカーネルハックに興味があるけど特にネタが無いんだよな〜って人向けの小ネタ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルに興味があるんだけど特に作りたいものってないんだよなーなんて割とあると思う訳です。俺とか。。。 まあ、kernelnewbiesのメーリングリストでもよく見る話題かと思います。この辺なんかもそうですね。 で、そんな時にオススメできるのがkmemleak。カーネルに組み込まれたメモリーリーク検出ツールです。 使い方は至って簡単でカーネルのコンフィグレーションにあるKernel memory leak detectorを有効にしたカーネルを普通に使えばOK。カーネルはメインラインのrcでもtipでもlinux-nextでも何でも良いと思います。 設定の場所はKernel Hacking -> Memory Debugging -> Kernel memory leak detectorにチェックをするのと、 その下のMaximum kmemleak early log ent
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
