カーネル関連について

カーネル設計思想に関して

大きく，「マイクロカーネル」と「モノリシックカーネル」が存在する． 基本的な思想は理解できているものとするので省く．

パフォーマンスに関する考察

マイクロカーネルとモノリシックカーネルの設計(https://upload.wikimedia.org/wikipedia/commons/6/67/OS-structure.svg)

図はそれぞれのカーネルの設計を示したものである． マイクロカーネルはカーネルに含まれない本来OSが持つべき機能はユーザ空間で動いているため， それらの動作の際には必ずカーネル空間とユーザ空間の移動が発生する． デバイスドライバもネットワークスタックもユーザ空間にあるのでこれらの動作には必ず大きなボトルネックがついて回る事になる．

Linuxのプロセスのメモリ空間とかについてのメモ

オブジェクトファイルが一緒だったら実は仮想メモリ空間に当てられてる物理メモリ空間は一緒． glibcもしかり． それらは多分mmapされてると思ってほぼ良い． SHAREDで．ただ，デバッグ情報は通常の実行にはマップされないらしいから，素直にmmapされてるわけでは多分なさそう．? コード部のところ(と言うか実際のオブジェクトファイル a.out とかには実はハンドラみたいなもの(先生がなんて読んでいたか忘れてしまった)がくっついている． この辺について，PLTとかGOTとか言うやつが該当しそうらしい．(https://keichi.dev/post/plt-and-got) そこに呼び出しがあったあと，実物(__関数名みたいな奴ら)を叩きにいく． いろんな意味があるけど，一つはLDPRELOADみたいなやつのため(標準ライブラリの関数とかを自作のものに一時差し替えたりするやつ) もう一つはglibcめっちゃでかいから全部一気にメモリにロードするのは邪魔なため． 他にも理由ありそうだけど，今わかったのはこの二つ． オンデマンドローディングとかいうやつ? ちなみにこのオンデマンドローディングみたいなのはUnixの?Linuxの?思想的には全くもってやってはならないことらしい． よく考えればそれはそうで，コード部のジャンプ先を実行時に書き換えるなんて何かの間違いでとんでもないところに飛んだら大変なことになる． ただパフォーマンスのためにglibcは?なのかgccは?なのかわかんないけどそれをしているらしい．

マルチプロセスとマルチスレッドに関して

基本的な差異は理解していて，おおよその違いはそこから容易に想像が可能であるためその部分に関しての記述はめんどくさいので避ける． そういえばセマフォはどうなってるのか聞き忘れたのでタイミングがあったら聞きたいけど，基本的にはmutexに違いもので，鍵が複数あるmutexみたいなのが正しいと思う． http://tooljp.com/windows/chigai/html/Programming/Mutex-Semaphore-chigai.html

flockみたいなのとpthreadで使うmutexがあるけど， mutexはユーザメモリ空間の変数でしかないので高速で，システムコールを伴わないのでユーザ空間とカーネル空間のコンテキストスイッチもない． flockはファイルシステムのメタデータ的な場所にあってそれを扱ってるらしい．

ところで，アドバイザリロックと強制ロックについてももしかしたら書いた方が良さげだけど気分がのらないのでやめる． ちょっとリンクだけはっとく． https://wiki.bit-hive.com/north/pg/%E5%8B%A7%E5%91%8A%E3%83%AD%E3%83%83%E3%82%AF%E3%81%A8%E5%BC%B7%E5%88%B6%E3%83%AD%E3%83%83%E3%82%AF