こんばんは、皆さんはチェックポイントアンドリストアでしょうか。そのようにやっていきましょう。今日はCRIUの話をします。
プロセスのチェックポイントイメージを取り、そのイメージからプロセスを再生する技術です。LinuxではだいたいCRIUを使えばできます。もちろん、コンテナのチェックポイント・リストアにも応用できます。
TenForwardさんの記事が詳しいですので是非そちらもお読みください。
何ができるかというところが気にかかるでしょうが、TenForwardさんの記事にある通り：
あたりが有益そうな用途でしょう。
続きを読むcgroup.event_control の概要特定のcgroupに何かが起こった時に、eventfdを経由してユーザランドに通知を送り込む仕組みがある。 cgroup.event_control は # an interface for event_fd() とされている。
cgroupを一つ作ると、原則そのファイルも新しく一つできる。あるcgroupに一対一で存在するという認識で良さそう。
root@ubuntu-bionic:~# mkdir /sys/fs/cgroup/memory/udzura-sample root@ubuntu-bionic:~# ls -l /sys/fs/cgroup/memory/udzura-sample total 0 -rw-r--r-- 1 root root 0 Jul 23 09:24 cgroup.clone_children --w--w--w- 1 root root 0 Jul 23 09:24 cgroup.event_control -rw-r--r-- 1 root root 0 Jul 23 09:24 cgroup.procs -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.failcnt --w------- 1 root root 0 Jul 23 09:24 memory.force_empty -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.failcnt -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.limit_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.max_usage_in_bytes -r--r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.slabinfo -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.tcp.failcnt -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.tcp.limit_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.tcp.max_usage_in_bytes -r--r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.tcp.usage_in_bytes -r--r--r-- 1 root root 0 Jul 23 09:24 memory.kmem.usage_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.limit_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.max_usage_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.move_charge_at_immigrate -r--r--r-- 1 root root 0 Jul 23 09:24 memory.numa_stat -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.oom_control ---------- 1 root root 0 Jul 23 09:24 memory.pressure_level -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.soft_limit_in_bytes -r--r--r-- 1 root root 0 Jul 23 09:24 memory.stat -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.swappiness -r--r--r-- 1 root root 0 Jul 23 09:24 memory.usage_in_bytes -rw-r--r-- 1 root root 0 Jul 23 09:24 memory.use_hierarchy -rw-r--r-- 1 root root 0 Jul 23 09:24 notify_on_release -rw-r--r-- 1 root root 0 Jul 23 09:24 tasks
で、今回はmemory controllerでの実装をまとめる（というか、他のcontrollerでの挙動を教えて欲しい...）。
eventfd とは...何かしらのイベント通知を待ち受けるためのファイル記述子（fd）。普通のfdなので、read(2)などで読み取り可能になるのを待つことができるなど、一般のファイル経由で作ったfdと同様にプログラムの上で扱うことができる。
昔、パイプを使ってプロセス間での通知を試したことがあったが、eventfdの場合はカーネルからのイベントもユーザ空間で待ち受けることができる。
cgroup.event_control に書き込むこのように錬成されたeventfdをread()することで、イベントが発生したらデータを読み取ることができる。ブロッキングIOの場合は読み取り可能になるまで待つ。このようにeventfd自体は他のものと同様にファイル記述子なので、ノンブロッキングにしたり、poll(2)とかepoll(7)とかそういうやつで多重に待ち受けたり、色々と扱いやすいし、むやみに新しい概念を覚える必要なく使える。
カーネルのドキュメント によると現在の最新のカーネルでは3つ存在する模様。
"<event_fd> <fd of memory.usage_in_bytes> <threshold>" というものを書き込む
<event_fd> <fd of memory.oom_control> を書き込む
/) では動かない1 を書き込むとOOMが無効になる
oom_kill_disable OOM が無効かどうか。0が有効、1が無効（二重否定感）under_oom 1 であれば、OOMされるべきプロセスがあり、現在停止しているところ"default": デフォルトの挙動。すなわちA->B->Cとcgroupがあった時、イベントがセットアップされた中で一番階層が低いcgroupにしか通知がされず、イベント登録がある階層までメモリプレッシャーの通知は伝播する"hierarchy": A->B->Cとcgroupがあった時、Cでメモリプレッシャーがあったら必ずB→Aとイベント通知は伝播していく"local": イベントの登録がそのものズバリのcgroupにない限り通知されない。例えば、A->B->Cとcgroupがあった時、CのメモリプレッシャーはCのイベントの有無に関係なくBより上には通知されない、デフォルトでは、Cにイベント登録がない場合、CのメモリプレッシャーはBに通知が行く明日はこれらのイベントを実際にコードで取り扱ってみる。
社で提出した振り返り資料をベースにパブリックでも書いとこうかと思う。
続きを読む