Kernel 勉強会

カーネルの配置

• /boot 以下に配置される
• config
  • ビルド時に指定されたオプションの明細
• initramfs
  • 起動時に利用される ramdisk イメージ
• sysvers
  • カーネルとカーネルモジュールが export しているシンボルとチェックサムの一覧
  • モジュールのビルド時に利用
  • モジュールのロード時に ABI の整合性をチェックするためにも利用
• System.map
  • カーネルのシンボルテーブルとアドレスの一覧
  • プロファイラなどで利用
• vmlinuz
  • カーネル本体
  • z がついているのは圧縮されているから

uname

$ strace -v uname
...
uname({sysname="Linux", nodename="oswald", release="3.10.0-1062.4.1.el7.x86_64", version="#1 SMP Fri Oct 18 17:15:30 UTC 2019", machine="x86_64", domainname="(none)"}) = 0
...

詳しくは man 2 uname man 2 はシステムコールの man

カーネルモジュール

• lsmod
  • カーネルモジュールの表示

process

• プロセスごとに /proc 以下が作られてスレッドごとに /task 以下ができる

$ ls -d /proc/*/task/* | head
/proc/10020/task/10020
/proc/10107/task/10107
/proc/10163/task/10163
/proc/10238/task/10238
/proc/1023/task/1023
/proc/10240/task/10240
/proc/10241/task/10241
/proc/10258/task/10258
/proc/10585/task/10585
/proc/10586/task/10586

• カーネル実行の流れ
  1. scheduler が次の実行するスレッドを決める
  2. プロセスが選択される
  3. システムコール
  4. handler にいく
  5. handler から scheduler にいく
  6. ぐるぐる

システムコール

• プロセス（厳密にはスレッド）がカーネル機能を呼び出す
• C の関数とカーネル関数の見た目はあまり変わらない
  • printf と fork を比較するとわかる
• これは libc がラッパーになっているため
• なので C のプログラムでライブラリメソッド呼ぶのとシステムコールを呼ぶのはあまり変わらない
  • 逆コンパイルをする `callq` で呼ばれている

int foo()
{
    return 2
}
int
main() {
  // return foo();
  return getppid();
}

重要なシステムコール

fork	現在のプロセスのコピーである新しいプロセスを作成する
execve	現在のプロセス内で実行しているプログラムを指定したプログラムと置き換え実行開始する
wait	fork で作成した子プロセスの終了を待つ
exit	プロセスの終了
clone	スレッドの作成

/proc/<pid>/stack

$ cat
<- とまってる

$ strace -p 15768
strace: Process 15768 attached
read(0, ^Cstrace: Process 15768 detached
↑ read システムコールでとまってる
 <detached ...>

$ sudo cat /proc/15768/stack
[<ffffffffba466c10>] n_tty_read+0x2b0/0xd10 <- ターミナルからなにかを読もうとしているのがわかる
[<ffffffffba462330>] tty_read+0x90/0x100
[<ffffffffba248d8f>] vfs_read+0x9f/0x170
[<ffffffffba249c4f>] SyS_read+0x7f/0xf0
[<ffffffffba78bede>] system_call_fastpath+0x25/0x2a
[<ffffffffffffffff>] 0xffffffffffffffff
＜こっちのほうがアプリケーションより＞

man の横の数字

1	ユーザコマンド
2	システムコール

ps の内容は書き換えられる

• 引数の 0 番目にコマンドが入ることを利用
• /proc/hoge/exe を見ると実行したコマンドをシンボリックリンクで確認できる

strace

• 実行しているコマンドの syscall の内容を見ることができる
• strace ls

strace 便利プション

• ‘-e’
  • 表示するシステムコールを絞り込む
  • ビックリマークで除外もできる

strace -e '!close' ls

• ‘-t’
  • タイムスタンプ
• ‘-p’
  • すでにあるやつを見る

strace -p <PID>

• ‘-k’
  • スタックトレースを表示する
  • システムコールの munmap がどう呼ばれているかがわかる

$ strace -k ls
munmap(0x7f5d3b94a000, 4096)            = 0
 > /usr/lib64/libc-2.17.so(munmap+0x7) [0xf8e27]
 > /usr/lib64/libc-2.17.so(_IO_setb+0x61) [0x7cd71]
 > /usr/lib64/libc-2.17.so(_IO_file_close_it@@GLIBC_2.2.5+0xaf) [0x7b14f]
 > /usr/lib64/libc-2.17.so(fclose@@GLIBC_2.2.5+0x1b7) [0x6e1f7]
 > /usr/bin/ls(close_stream+0x19) [0x412399]
 > /usr/bin/ls(close_stdout+0x14) [0x40a994]
 > /usr/lib64/libc-2.17.so(__run_exit_handlers+0xd8) [0x39ce8]
 > /usr/lib64/libc-2.17.so(exit+0x16) [0x39d36]
 > /usr/bin/ls(main+0x12db) [0x403beb]
 > /usr/lib64/libc-2.17.so(__libc_start_main+0xf4) [0x22554]
 > /usr/bin/ls(_start+0x28) [0x40434c]

コンテキストスイッチ

• CPU 上で動作するプロセスやスレッドが変わることをコンテキストスイッチと呼ぶ
• vmstat の cs 欄がコンテキストスイッチの回数
  • ちなみに vmstat の 1 行目は起動してからの平均
• in がモード切替の値
  • vmstat -w 1
• 同一プロセス内の切り替え=>コストが低い
• プロセスをまたぐ場合=>コストが高い
• モード切り替えはユーザランドとカーネルの切り替え

スケジューラと Tick

• tick はいわゆるタイマーでこれがよばれるとスケジューラはスレッドを切り替える
• 一定時間で tick が呼ばれる
• IO wait になったら tick がなくてもスレッドを切り替える

スレッドの状態

R	実行しているか実行待ち
D	割り込み不可なイベント待ち（ disk 待ちなど）
S	割り込み可能なイベント待ち
T	シグナルやデバッガで一時停止中
Z	実行は終了（親プロセスへ渡す終了ステータスを維持）
X	終了

run queue

• load average = run queue の平均長
• top や uptime で見ることができる
• 左から 1 分、5分、15 分
• 例えば load ave.が 2 なら常に 2 つの CPU が稼働していることを示している

$ uptime
18:02:25 up 323 days,  7:22,  1 user,  load average: 0.06, 0.03, 0.05

$ top
top - 18:07:41 up 323 days,  7:27,  1 user,  load average: 0.04, 0.03, 0.05

プロセスが動く CPU を指定する

• numactl、 taskset コマンドなどで設定できる
• systemd でやるのが実用的
• /proc/<pid>/status を見るとわかる
• Cgroups というのもある
  • https://wiki.archlinux.jp/index.php/Cgroups

taskset 0x2 cat &
grep Cpus_allow /proc/{pid}/status
Cpus_allowed:   2
Cpus_allowed_list:      1

$ ps axu | grep mig
root        13  0.0  0.0      0     0 ?        S     2018   1:41 [migration/1]

Cpus_allowed:   2
Cpus_allowed_list:      1

スケジューラのシステムコール

• nice
  • 優先度を設定
• sched_yield
  • CPU 割当が不要になったので他のプロセスにスケジュールしてよいとスケジューラに通知する
  • 何もせずにスケジューラ呼び出しになるので最小のシステムコールといえる

inode

• ファイルシステム内でファイルを示す起点になるデータを保持
• inode さえ分かればデータに到達することができる
• サイズ、使用ブロック数、リンク数のカウント、アクセス権限、 UID、 GID などのメタデータ
• 表現はファイルシステムによって違う
• stat コマンドでみることができる

$ stat hoge.yaml
  File: `hoge.yaml'
  Size: 674         Blocks: 8          IO Block: 4096   regular file
Device: fc01h/64513d  Inode: 13017       Links: 1
Access: (0644/-rw-r--r--)  Uid: (111300/ me)   Gid: (  100/   users)
Access: 2019-09-25 10:31:13.024134209 +0900
Modify: 2019-09-25 10:31:13.024134209 +0900
Change: 2019-09-25 10:31:13.024134209 +0900

• ls -i で inode とファイル名を表示できる
• rm コマンドでは unlink をしているだけ
  • だからファイルサイズが大きいやつを rm しても実行時間はあまり変わらない
• link が 0 になったら開放するかはカーネル次第

$ strace rm test
...
unlinkat(AT_FDCWD, "test", 0)           = 0

ファイルディスクリプタ

• プロセスごとにファイルディスクリプタテーブルという番号とファイルの対応表が作られる
• プロセス間でファイルディスクリプタテーブルは別
• ファイルディスクリプタは栞みたいなもん
  • open システムコールをすると 0 番の栞をつかってくださいっていう
  • 何人も同じ本を読んでいるとファイルディスクリプタ（栞）があると便利
• lsof で確認できる
  • 0u みたいなのがファイルディスクリプタのスロット
  • 136,0 が stat で表示される Device のと対応している
  • ファイル名の左隣が inode 番号を示してる

$ lsof
bash      31451  me    0u      CHR     136,0      0t0         3 /dev/pts/0
bash      31451  me    1u      CHR     136,0      0t0         3 /dev/pts/0
bash      31451  me    2u      CHR     136,0      0t0         3 /dev/pts/0

• ls -l /proc/<pid>/fd をやるとファイルディスクリプタとそのリンクを見ることができる
• cat /proc/<pid>/fd/1 とかやるとそのプロセスのファイルディスクリプタの番号の内容が見れる
• ブロックデバイス自体もファイルディスクリプタを取得して write/read できる
  • パーティションを切るときとか
  • パーティションを切るシステムコールはない
• cat について知らないとき

$ cat <- 実行すると止まっている用に見える
$ pidof cat
$ strace -y -p <pid>
read(0, <- readしようとして止まっているのが見える
$ lsof -p <pid>

BufferedI/O と DirectI/O

• 通常は BufferedIO
• カーネルの Page Cache が間に入る
  • プロセス -> PageCache -> ディスク
• DirectI/O
  • 直接アプリケーションのバッファをブロックデバイスに書き込む
• 確認方法
  • lsof +

仮想環境との違い

• ハードウェアのアクセラレーション
  • /dev/kvm を通じて行う
• iocontrol システムコールでやる

BufferedIO の動作の流れ

• ページキャッシュには 2 種類ある
  • データの変更がディスクに反映されている（ clean）
  • データの変更がディスクに反映されていない（ dirty）
• 時間が経つと変更のあったキャッシュをディスクにフラッシュする
  • 時間は 5 秒（ RHEL7）
  • dirty がめちゃくちゃ多いと時間を待たずにフラッシュする
• フラッシュは io request queue にいれる
  • ブロックデバイスごと（1本）
  • [/dev/sda] <- [hoge に書いて] <- [huga に書いて]…
  • 近代は CPU が増えているので queue にいれるときにコンフリクトしないように Lock する
• io elevetor
  • queue をマージしたり並び替えたりして早くしようとするデザイン
  • request queue を dispatch queue に変えて入れる
• multi queue
  • CPU ごとにリクエストキューを用意する
• iostat
  • request queue などの様子を確認できる

proc

• 左が現在の inode 数
• 右はいますぐに用意することができる inode 数

$ cat /proc/sys/fs/inode-nr
49488  21516