プロセスとスレッド 基礎

シェルが curl を走らせると fork()、続けて execve() を呼び、カーネルは task_struct、アドレス空間の mm_struct、ディスクリプタ表、PID を確保する。そのうち最大で、圧倒的に空っぽなものはスタックの上から始まる —— 128 TB のユーザ半分に沿ってドラッグし、ズームを引いて、マッピングがその中に消えるまで戻してみてほしい：

そこで見つかるものがどれだけ少ないかに注目してほしい。9 つのマッピング —— text、rodata、data、ヒープ、共有ライブラリ 3 つ、スタック、vDSO —— 合わせて 5.5 MB、それが座っている空間の 100 万分の 4 パーセントだ。アドレス空間はメモリではない。47 ビットの名前空間に針が数本刺さっているだけで、ページテーブルがその針の在処を言う索引だ。

fork() がコピーするのはまさにその索引だ。データはコピーしない —— 親と子は同じ物理フレームを指し続ける。親の常駐サイズをドラッグして、データが動かないままページテーブルだけが育つのを見てほしい：

親が 1 GB のとき、カーネルは 262,144 個の葉エントリを歩いて 2 MB の新しいページテーブルを作り、データは 1 バイトもコピーしない。 1.1 ms はそこから来ていて、fork がタダではなく RSS の 1 次関数である理由でもある：64 GB では同じ歩行が 128 MB のテーブルと 67 ms になる —— Redis のバックグラウンド保存が隠さなければならない停止だ。

この取引は両側とも条件付きだ。共有フレームはすべて読み取り専用でマップされるので、子の最初の書き込みはカーネルにトラップする。親の 1 GB に対する書き込み量をドラッグして、コピーが積み上がるのを見てほしい：

マスではなく請求書のほうを見てほしい。フォールト 1 回が 1.2 µs —— 越境 2 回、フレーム確保 1 回、4 KB コピー 1 回 —— でページは 262,144 枚あるので、全部 書く子は 1.1 ms の fork に加えて 325 ms をフォールトに払う。コピーオンライトは安いのではない。先送りなのであって、全部に触る子は請求書を全額受け取る。

ディスクリプタ表もコピーされる —— ただし表だけだ。その下にあるオープンファイル記述、つまりオフセットが住んでいる場所は共有される。親と子で交互に書いてから、別々の open() 2 回に切り替えてみてほしい：

両方のディスクリプタが同じオープンファイル記述を指しているので、f_pos は書き込みごとに 1 回進み、4 バイトのレコード 12 個が端から端まで並ぶ。プロセスごとに自前の open() を与えると両方ともオフセット 0 から始まり、12 回の書き込みのうち 11 回が上書きされ、ファイルは 4 バイトになる。

続いて execve() がアドレス空間を捨て、task を残す。 1 歩ずつ進めてから O_CLOEXEC を入れて、そのディスクリプタが一緒に行くかどうかを決めてみてほしい：

新しいイメージがマップされた瞬間、4 つのマッピングは消え、4 つの task フィールドはそのまま残る —— 同じ PID、同じ cwd、同じ credentials、同じ fd 3。最後のものは漏洩だ：O_CLOEXEC がなければ、たまたま握っていたディスクリプタは exec した先のプログラムに手渡される。サーバのリッスンソケットが自分で spawn した子の中に現れるのはこれだ —— フラグ 1 つの違いで、コンパイラには見分けがつかない：

int fd = open(p, O_RDWR);             /* 漏れる */
int fd = open(p, O_RDWR | O_CLOEXEC); /* 漏れない */

どちらもコンパイルもテストも通る。同じ形は 1 階層上にもある ——C ライブラリ自身のバッファだ。printf はプロセスメモリに書くので fork がそれも複製する。何行か印字してから fork してみてほしい：

両方のプロセスが終了時に同じバイトをフラッシュするので、fork 前の printf 4 回はパイプに 8 行出る。先に fflush(stdout) すれば空のバッファが残り、複製するものがない。man ページは何も言わず、警告も出ない。

pthread_create はスレッド用の syscall を呼ばない。呼ぶのは clone() ——fork() が呼ぶのと同じもの —— でフラグワードが違うだけだ。人が「プロセス」「スレッド」と呼んでいるものは 1 本のダイヤルの両端であって、どこで止めるかについてカーネルに意見はない。

そのダイヤルには 5 つのくぼみがあり、馴染みのある名前は両端にしか現れない。共有フラグを 1 つずつ足して、子がリソースごとに自前のコピーを持つのをやめていくのを見てほしい：

フラグを 1 つも立てなければ fork() になる ——私的なコピーが 5 つ。5 つ全部 立てればスレッドになる —— アドレス空間 1 つ、作業ディレクトリ 1 つ、ディスクリプタ表 1 つ、シグナル処理 1 つ、スレッドグループ 1 つ。あいだはすべて合法で、有用なものもある：CLONE_VM なしの CLONE_FILES は、自前のメモリを持つ子とディスクリプタを共有する。

そのスレッドの値段は 2 つの別々の数字で、本当にあるのは片方だけだ。スレッド数を動かして、予約されたアドレス空間と常駐しているメモリが離れていくのを見てほしい：

1,024 スレッドの時点で、プロセスは8 GB を予約し、実際に使っているのは 8 MB だという点に注目したい。 8 MB のスタックは ulimit -s、つまり予約であり、起動直後のスレッドが触るのは 2 ページだ。本当にあるコストはスレッドあたり 25 KB のカーネルメモリ —— 16 KB のカーネルスタックと 9 KB の task_struct —— で、そちらは RSS には現れない。

だから上限を決めるのはあなたのメモリではなくカーネルのメモリで、しかも普通はまったく無関係な第 2 の上限が先に来る。マシンの RAM をドラッグして、2 つの上限が入れ替わるのを見てほしい：

threads-max は総 RAM ÷ 32 ページなので、16 GB のマシンは 131,072 スレッドを許す。しかし pid_max の既定は 32,768 で、スレッドは 1 つずつ消費するので、32,768 が本当の答えだ —— 16 GB のマシンでも 1 TB のマシンでも、誰かが sysctl を上げるまで同じだ。2 GB ではメモリ側の上限が先に効き、16,384 で止まる。

アドレス空間を共有することには言語レベルの帰結がある：グローバル変数は、何スレッドが読もうと1 つのセルだ。スレッドを選んでから、宣言を thread_local に切り替えてほしい：

static int n では 4 スレッドとも同じワードをインクリメントするので 4 と読め、 1 回ごとが競合になる。thread_local と宣言すると、コンパイラは絶対アドレスではなく %fs:-0x8 を出し、各スレッドは自分の 1 を読む。現場のスレッドごとアロケータキャッシュも CPU ごとカウンタも、全部この技だ。

並行タスク 1 つにカーネルスレッド 1 本という方式は、メモリが尽きるはるか手前で成り立たなくなる。タスク数をドラッグして、ランタイム自身のタスクと1 タスク 1 スレッドの値段を比べてほしい：

100 万並行タスク では、goroutine は 1 つ 4 KB で 4 GB、スレッドは 1 つ 33 KB で 33 GB —— しかしスレッドの棒は 32,768 でローズに変わる。メモリよりずっと手前で pid_max が止めたからだ。M:N の論拠はそこにある：スレッドが遅いのではなく、スレッドには硬い個数があるということだ。

その請求は最初のブロッキング syscall で来る。カーネルに入ったタスクは、直前まで走っていた OS スレッドを握ったままだからだ。ブロック中のタスクの割合を上げてから、ハンドオフを入れてほしい：

ハンドオフなしで 100% まで振り切ると、8 本の OS スレッドが read() に座ったまま、ランタイムは使えるコアがゼロになる。Go の sysmon は 20 µs 後に P を取り戻して代わりのスレッドを起こす。 Java の仮想スレッドはブロック地点でアンマウントする。どちらもランタイムから見えないブロックでは同じように壊れる —— マップされたファイル上のページフォールト、CGO 呼び出し、dlopen。

タスクのスタックも「ある点までは安い」ものだ。Go のスタックは 2 KB から始まり、フレームが入らなくなると倍になり、生きているフレームを全部コピーする。呼び出しの深さを上げてみてほしい：

1,024 フレームの深さでスタックは 5 回倍化して 64 KB になり、62 KB をコピーしている —— 最初から 8 MB 予約するpthreadが決して払わないコストだ。「goroutine は安い」はメモリとスケジューリングの主張であって、syscall や深い再帰の主張ではない。

x86-64 には ring が 4 つあり、使うのは 2 つだ —— アプリケーションは ring 3、カーネルは ring 0。ARM64 では EL0 と EL1 と呼ぶ。カーネル側の半分もあなたと同じページテーブルで記述されており、 ring 3 の読み取りを止めているのはカーネルではなくハードウェアだ。

つまり境界はアドレスの属性であって、別のメモリのことではない。アドレスを 64 ビット全体にわたってドラッグし、2 つの判定が食い違うのを見てほしい：

空間の真ん中はそもそもメモリではない、という点に注目したい。正準なのは下位 128 TB と上位 128 TB だけで —— ビット 48〜63 はビット 47 の複製でなければならない —— そのあいだのアドレスは、ページテーブルが引かれる前にアドレスの形そのもので例外になる。カーネル半分はマップされているのに ring 3 は読めない：それはページテーブルエントリの U/S ビットで、 MMU がアクセスごとに検査している。

正規の手順で ring 0 に入るには 8 ステップかかり、最初のステップは CPU がアトミックに済ませるので、途中の半端な状態は観測できない。syscall を 1 回ぶん歩いてみてほしい：

ページテーブルがどこで変わるかを見てほしい。ステップ 5 が KPTI だ。 Meltdown 以降、ユーザ側のページテーブルにはカーネルが入っていないので、入るには CR3 を書き、出るにも書き戻す。 8 ステップのうち 2 つは 2018 年のハードウェアバグのためだけに存在し、そしてその 2 つがいちばん高い。

どれだけ高いかは、あなたのカーネルが何を有効にしているかで決まる。緩和策の構成を切り替え、syscall のレートを上げて、コアの棒が動くところまで持っていってほしい：

素の越境は命令 55 ns 分だ。KPTI + PCID は CR3 の 2 回の書き込みに 50 ns を足す。 PCID なしの KPTI は 190 ns を足す —— 書き込みのたびに TLB 全体が流れるからだ。毎秒 10 万 syscall —— ごく普通の忙しいサーバ —— なら PCID ありでコアの 1.1%、なしで 2.5%。毎秒 100 万 では PCID ありで 11%、なしで 25% だ。

いちばん安い越境は、起きない越境だ。clock_gettime はカーネルが全プロセスにマップするページを読むので、ring 3 から出ない。呼び出しレートを上げてみてほしい：

毎秒 100 万回 —— ホットループでリクエストごとにタイムスタンプを取るのがまさにこれだ —— では、vDSO がコアの 2.5%、syscall 経路が 34% を食う。14 倍だ。仕掛けは何もない：カーネルが共有ページに時計を書き、 vDSO がユーザ空間で算術をするだけだ。io_uring は同じ発想を I/O に適用したものだ。

フォールトもこの境界を越えるし、値段はどれも同じではない。ポインタを 16 ページ分ドラッグして、各アクセスが実際にいくらかかるか読んでほしい：

幅は 5 桁ある。TLB ヒットが 1 ナノ秒、マイナーフォールトが 900 ns、メジャーフォールトはページをデバイスから取ってくるので 100 µs、SIGSEGV は 2.2 µs でその後プロセスは消える。一覧でいちばん安いものが、唯一プログラムを終わらせるものだ —— そしてそれが良いケースでもある。高いほうは黙って走り続けるからだ。

だからスループットを求めるサーバは syscall を速くしない —— 数を減らす。仕事量を毎秒 100 万操作に固定したまま、数個ずつまとめて投入してみてほしい：

越境は操作ごとではなく投入ごとなので、深さ 128 の io_uring キューは毎秒 100 万回の越境を 7.8K に変える —— コアの 0.105 から 0.0008 へ。仕事が安くなったのではないし、 ring の切り替えは今も 55 ns だ。ただ回数が 128 分の 1 になっただけだ。

スイッチが起きるのは、タイマが走行中スレッドのスライスを使い切ったとき、そのスレッドが I/O でブロックしたとき、より緊急なものが起きたときだ。カーネルはレジスタを保存し、次に走るスレッドを選び、そのレジスタを読み込む。変わるのは、入ってくるスレッドが同じプロセスのものかどうかだ。

その 1 問が、6 ステップのうち 1 つが起きるかどうかを決める。スイッチを歩いてから、入ってくるスレッドが誰かを変えてほしい：

ステップ 4 が switch_mm で、同一プロセス間のスイッチはこれを飛ばす。入ってくるスレッドはすでに正しいページテーブルを持っているので、 CR3 は書かれない。直接の差はそれだけだ —— スレッドで 730 ns、プロセスで 930 ns。もしこれで話が終わりなら、 1 リクエスト 1 プロセスは 27% 悪いだけで、誰もランタイムなど書かなかった。

話は終わらない。TLB のキーが CR3 だからだ。入ってくるスレッドのワーキングセットを大きくして、持っていたはずの変換を歩き直す値段を見てほしい：

曲線が登るのをやめる場所に注目したい。L2 STLB は 1,536 エントリなので、 6 MB を超えるワーキングセットはそもそも全部はキャッシュされていない。8 MB から上では、フラッシュが余計に負わせられるのはページウォーク 38 µs までだ。この天井は良い知らせのほうで、38 µs はそれを起こしたスイッチの直接コストの 41 倍にあたる。

だから TLB はフラッシュされなくなった。各エントリはプロセス id を持ち、 Linux は CPU あたり 6 個を保持する。1 コアにプロセスを足して、タグを使い切らせてみてほしい：

TLB_NR_DYN_ASIDS は 6 だ。1 CPU を回る 6 プロセスまでは毎回のスイッチで変換を保持し、930 ns で済む。7 番目が誰かを追い出すと、そこからはスイッチごとに 930 ns プラス歩き直し —— 2 MB のワーキングセットなら 13 µs だ。PCID は「フラッシュが消えた」ではなく、「ランキューが短ければフラッシュは消えている」だ。

キャッシュにはそもそもそんなタグ付けがない。もう一度ワーキングセットを広げ、直接コストが、スイッチが引きずってきた 2 つのものに埋もれていくのを見てほしい：

ワーキングセット 1 MB では、直接の 930 ns は棒の左端の細い線だ。ページウォーク 6.4 µs と、12 GB/s でのL2 再充填 87 µs が、実コストを 95 µs にする —— カーネルのカウンタが報告する数字の 102 倍で、上限は 127 µs だ。 Li、Ding、Shen は 2007 年に同じ形を測っている：間接コストは数マイクロ秒から 1 ミリ秒超まで変わる。

だからスケジューラの仕事は、許されるかぎりスイッチしないことだ。タイムスライスを縮めて、スイッチが取っていくコアの割合を見てほしい：

出荷時の既定 0.75 ms では、スイッチはコアの 0.097% —— 見えない。スライスを 5 µs まで下げると 12.7% になり、上で見たキャッシュ効果すべてが 150 倍の頻度で起きるようになる。プリエンプション粒度は自由に回してよい公平性のつまみではない。税率だ。

そしてそれこそがスレッドプールが実際に選んでいるものだ。CPU に 200 µs、待ちに 2 ms を使うリクエストでプールを広げ、スループットとレイテンシが離れていくのを見てほしい：

スループットは 88 スレッドで飽和し —— 8 コア × 実時間対 CPU 時間の 11 倍 —— 4,096 までずっと平らだ。レイテンシは違う：ひざで 2.2 ms、512 で 13 ms、4,096 で 105 ms。ひざを超えたスレッドは何も買わず、遅延を足すだけだ。

この節から持ち帰る価値のある不変条件はこれだ：コアを取れない実行可能スレッドは待っているのではなく、他の全員を待たせている。プールサイズは容量のつまみではない。それは、前段に置いて捨てることもできたはずのキューを、自分のプロセスの内側に置くと決めた、その長さだ。

毎秒 10 万スイッチ —— ごく普通の忙しいサーバ —— なら、あなたのコードが走る前にコア 0.07 本が消えるだけで、大したことはない。毎秒 560 万 では 8 本中 4.1 本が消え、残りの 3.9 本は冷えたキャッシュで走る。警報を出すべきはレートではなく、仕事あたりのレートだ： 1 リクエスト 2 スイッチは健全、20 なら設計の問題だ。

どの棒が先にローズになるかに注目したい。8,192 並行リクエスト で1 リクエスト 1 プロセスは 24 GB を食い尽くす。1 リクエスト 1 スレッドは 32,768 まで生き延び、そこで pid_max に止められる —— メモリにではない。タスクは同じマシンで 420 万に届く。 1 リクエスト 1 プロセスが間違いなのではない —— nginx も Postgres も使っている —— リクエストごとにやるのが間違いだ。

fork と execve で 355 µs、pthread_create は 25 µs、go func() は 300 ns。毎秒 1,000 で 0.36 / 0.03 / 0.0003 コアだ。

• 1 リクエスト 1 プロセス。1 つ 3 MB の私的 RSS、そして親のページテーブルに比例する fork コスト。
• 上限のないスレッドプール。天井は pid_max の 32,768、ひざは 88 だった。
• 非同期タスク内のブロッキング呼び出し。下の OS スレッドを固定し、そこに並ぶすべてを飢えさせる。
• 同期なしの共有可変状態。スレッドはアドレス空間を共有する。言語はそれを思い出させてくれない。
• レイテンシのためにスケジューラ粒度を触る。スライスが 50 µs を割ると、そのために全コアの 1% 以上を払っている。