カーネルコードの歩き方 ‐ ソースコードを読むための勘所を知る
数千万行に及ぶLinuxカーネルのコードのうち、どんなときにどこのコードを読めばいいか、そのときに何を手がかりにすればいいか、などについてお話します。 本記事は、TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 「カーネルコードの歩き方」というタイトルでお話しする武内覚と申します。ふだんはsatと呼ばれています。社会人1年目から15年ぐらいカーネルの開発とサポートをずっとやってきました。今も必要に応じてカーネルソースを見ています。 本LTで学べるのは「Linuxのカーネルソースの読み方についての勘所」です。直接読んでいくというより、もう少しメタな
Interactive map of Linux kernel
image/svg+xml Linux kernel map Constantine Shulyupin © 2007–2022 Constantine Shulyupin www.MakeLinux.net/kernel/map virtual logical electronics I/O memory CPU HI char devices HI subsystems address families sockets access protocols network interfaces networking Virtual File System block devices storage virtual memory memory access logical memory Page Allocator memory threads processes Scheduler int
Linuxのloadavgが約7時間ごとに上昇する現象の原因 - Mackerel お知らせ #mackerelio
Mackerelチームのエンジニアのid:itchynyです。 「mackerel-agentを入れるとloadavgが7時間ごとに上昇する」 先日、このような問い合わせを複数のお客さまから受けました。私も実験してみたところ、確かに再現しました。EC2 t2.microにmackerel-agentを入れて簡単なログ監視とプロセス監視を設定し、数日放置しました。 確かに、約7時間ごとにloadavgが上昇しています。この周期のcronの設定はしておらず、またmackerel-agent内部でも7時間ごとに行う処理はありません。しかし、プラグインを多く入れるほどloadavgのピーク値も上がります。 本エントリーでは、この現象の原因について説明します。 loadavgが上昇する原因を調べるには、まずloadavg自体がどう計算されているかを知る必要があります。 まずは、Linuxがloada
xv6のメモリ管理周りのコードリーディング - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
xv6のページング周りをちょっと見てたので記録をφ(..)メモメモ 参照したドキュメントはbook-rev10.pdfです。 book-rev10.pdfのP21、 Figure 1-2にxv6のメモリレイアウトがあります。 仮想アドレスの0から0x80000000がユーザー空間で、0x80000000〜0xFFFFFFFFがカーネル空間ですね。カーネル空間のうち先頭の0x100000バイトはBIOSの領域となってます。 カーネルのアドレス空間はvm.cにあるkmap構造体で管理してます。 static struct kmap { void *virt; uint phys_start; uint phys_end; int perm; } kmap[] = { { (void*)KERNBASE, 0, EXTMEM, PTE_W}, // I/O space { (void*)KERN
Linuxカーネルを読む前にやったこと - komukomo’s diary
「カーネルのコードがよくわからない。Linuxカーネルに関する本を読んでもいまいちしっくりこない。」 から、「読めば理解できそう..!」 になるまでにやったことのまとめ。 はじめに 低レイヤの話がわかるようになりたかった。 カーネルの中身が知りたかった。 とりあえず本を読もうと思い詳解 Linuxカーネル 第3版を読んだが知識がなさ過ぎてよくわからない。 知らない用語だらけで都度調べればなんとなくはわかる気もするが、いまいち頭に入ってこない。 今思うとそもそもCPUの話なのかカーネルの話なのかさえよくわからない状態で読んでいたような気がする。 そんな状態を克服するためにやったことをまとめておく。 学習前 学習前の自分の知識はこんな感じだった。 知っていた データ構造とアルゴリズム 論理回路 C言語（研究室で数値計算に使える程度。構造体やポインタくらいならわかる。） よく知らなかった OSが
TIME_WAITに関する話
3. 自己紹介 - まぁまぁ MySQL でご飯食べてます - 一時期は Resource Monitoring や KVS にも 力入れてました - ネットワーク的には素人です - Linuxとハードウェアは嗜む程度 - disk I/O にはむかしから興味あります - その他 slideshare はこちら - http://www.slideshare.net/takanorisejima/ 4. 本日のお題 - kernel 新しくしたりすると、TCP的に意識したほ うが良い変化が見つかるので - 今日は、Webアプリケーションサーバの観点か ら、 connect(2) する際に気になる TIME_WAIT について、書いてみようかと思います - 有識者からのマサカリを、強く歓迎いたします 5. 最初に参考資料 - この二つの記事を読んでいただけば、それで概 ね良いと思うんですが
TCP再送タイムアウト時間の規格と実装 - co1row’s diary
先日、アンドリュー・タネンバウム先生のコンピュータネットワーク第5版を読んでいると気になる記述が出てきた。 曰く、TCP再送タイムアウト時間（RTO）は下記の式で求められる。 RTO = SRTT + 4 * RTTVAR SRTTとは平滑化したRTT値、RTTVARとは標準偏差…ではなく平均偏差（計算の簡略化のため）である。単にRTT値だけを元にタイムアウト時間を設定してしまうと、RTT値のブレが大きいときに不要なタイムアウトが発生しやすくなる。なので平均偏差も足しましょう…それも4倍もしておけば、いくらなんでもパケットが到達して相手が生きているならば応答が返ってくるはずだろう、と。そういう式である。OK、話はわかった。 しかし信じがたい記述が続く。 再送タイマー最小値は1秒となっている。これはスプリアス再送を防ぐために選ばれた値である。 本当だろうか？だったら計算なんてする必要はない。
Out of memory and no killable processes... のカーネルパニックを起こしたい - hibomaの日記
イントロ dsas.blog.klab.org こちらのエントリを拝見したのだが Out of memory and no killable processes... というログを出してカーネルパニックするケースがあるのだなと初めて知った。 幸いにして、過去に同様のメッセージを出すカーネルパニックには遭遇したことがない。あるいはログが取れてなくて気がつかなかっただけかもね! モチベーション 故意に異常を起こして、このカーネルパニックを見てみたい 🔥💀 Out of memory and no killable processes ... のコード 該当のログを出してカーネルパニックするコードは out_of_memory に書かれている (ソースは CentOS7.4 1708 ) /** * out_of_memory - kill the "best" process when w
LinuxカーネルHack: ICMPエコー発、procファイルシステム着 (gdbのwatchを使うよ) - 佐野デジタル研究所
はじめに 前回に引き続き、ICMPまわりを追っていこうとしたら、大幅に脱線して、procファイルシステムに到着。 カーネルを少しいじりつつ、gdbの変数監視機能(watch)を利用することで、/proc/sys/net/ipv4/icmp_echo_ignore_allへの書き込みを監視することに成功した。 脱線のへの道のり ICMPエコーはicmp_echo関数によって処理される。 icmp_echo関数を見ると、net->ipv4.sysctl_icmp_echo_ignore_allフラグが立っていない場合は、 ICMPエコーを返さないようだ。 % cat net/ipv4/icmp.c [...] /* * Handle ICMP_ECHO ("ping") requests. * * RFC 1122: 3.2.2.6 MUST have an echo server that
cgroupのv1とv2の切り分け的なところ - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
cgroupはv1とv2という2つの実装（と言っていいのか？）があってそれらはkernel/cgroup.cで一つのコードベースにまとまっているのでコード読んでで混乱するなーというところで、誰得なめもを。 特に、4.1とかのカーネルだとv2のコードはまだ正式版となってないけどマージはされていて、DEVELsane_behaviorというオプションを使うことでv2の機能が使えるようになってます（参考： Linux 3.16 から試せる cgroup の単一階層構造 (1) - TenForward）。今はv2がちゃんと入っているのでこのオプションは不要で、cgroupのマウント時にcgroup v2としてマウントするかどうかで切り分けできます。cgroup_mount()のis_v2がそれです。 2083 static struct dentry *cgroup_mount(struct f
Linux スケジューラーのコア実装とシステムコール - Qiita
はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ
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カーネルの場合、データとリ
Linux カーネルを読もうとするこれからの自分へのまとめ - 戦場のプログラマー
2015 - 10 - 31 Linux カーネルを読もうとするこれからの自分へのまとめ WIP Linux カーネル まとめ Linux カーネル 読むぞーって思ってたけどとりあえずクローンしたはいいけどこれどうしたらええんやろって思って 3 日坊主になってしまっていたので、最近 カーネル の話をよく聞くようになったからまた性懲りもなく Linux カーネル をクローンしました。 カーネル の入手方法 まず Git 入れてます。 sudo apt-get -y install git sudo yum -y install git おもむろに The Linux Kernel Archives を訪れます。 おぉ、サイト全体 SSL 化されてるんだな。 こういうサイト最近増えたよね。 PROTOCOL のリンクを踏むと HTTP だったら RFC に飛ばされたりします。うーん感慨深い。
Linuxのブートプロセスを追うときに見るべきファイル(x86_64編) - Qiita
4.0というか4/25時点のLinusツリーのHEAD リアルモードでbzImage(vmlinuz)の先頭から呼ばれる場合(LILOから呼ばれるときだっけ？) arch/x86/boot/header.S 圧縮されたカーネル(bzImage)の先頭にあるコード(setup.elf)のうちの一つ エントリポイント_startがある mainを呼ぶ arch/x86/boot/main.c mainがある いろいろハードウェアを初期化する go_to_protected_modeを呼ぶ arch/x86/boot/pm.c go_to_protected_modeがある setup_idtとかsetup_gdt等でプロテクトモードへ入る準備をする protected_mode_jumpでcode32_start(startup_32がある場所)へジャンプする startup_32は0x100
Linux Kernel Hack入門編 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2014の25日目ですヽ(=´▽`=)ﾉ 今回はLinux Kernel Hack入門編ということで入門的なことを書いてみたいと思います。 まず使用する環境ですけど最近出たばっかのFedora 21のWorkstationにしました。まあ、今回の内容的にはディストリビューションは問わないんですが、多くの人が馴染んでいるであろうfedora系というかパッケージマネージャがyumということでこれにしてみました。 自分は普段Arch Linuxなんですけど、こっちだとkernelのmake install時にちょっとしたスクリプトを書く必要があったりするのもあって、fedoraのほうが手軽かなというのもあります。 カーネルコード・リーディング ブラウザベースでコード・リーディング 読めるソースは大概メインラインのカーネルということになりますが
カーネルおさんぽまっぷ超入門
Kernel/VM Advent Calender 2013 7日目 カーネル/VMはておくれなすごい人がけっこう集って、ネタとか披露しているようです． 今年のAdvent Calenderも既に濃い内容が集っています． でも、私達パンピーにはカーネルとかちょっと難しすぎてそもそも カーネル/VMという主題自体敬遠しちゃう…… ということで本当にカーネルの第一歩をやってみよう、というのがこの記事です. 記事タイトルはえりっく氏(@siritori)から無断で肖ってます．ありがとうございます 今年の他の記事が高度な内容なので この記事が低レベル(低レイヤということでなく本当に程度が低いという意味で)ですいません． 普段からカーネル/VMに参加してる皆様、さようなら. カーネル/VM界隈わいわいしてておもしろそうだけど怖くて敬遠してる方々、こんにちは． 前置きはこのぐらいで本文行きます. 少々
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hiboma/kernel/steal.md at master · hiboma/hiboma