Documentation/cgroup-v1/memory.txtのめも

コードではなくてドキュメントもたまには読みましょうということで、Documentation/cgroup-v1/memory.txtです。

accounting == 課金です。以下のめもは本文を自分が分かれば良い程度に大雑把に意訳した感じです。 機械翻訳はとかしてないので安心ですね?

2.2. Accounting

Figure 1の説明のところ。

  1. 課金は各cgroupの単位
  2. 各mm_struct構造体は自分がどのcgroupに属しているかわかる
  3. 各page(構造体だよな)はpage_cgroupへのポインタを持っていて、ここからどのcgroupに属しているかわかる

課金は以下の流れで行われる。

  1. mem_cgroup_charge_common()が呼ばれて、最低限のデータの設定、メモリの使用量が設定値を超えるかチェック
  2. 超えるようならこのcgroupを対象にページ回収の処理を行う。詳細はreclaimのセクションで。
  3. すべてが上手いこと行くようなら、page_cgroupの更新をする。page_cgroupはLRUを持ってる。page_cgroupはbootやメモリホットプラグでメモリが追加されたときにインスタンスが確保される

2.2.1 Accounting details

すべての無名ページ(RSS)とページキャッシュは課金される。reclaimableじゃないページとLRUで管理されないようなページは課金されない。ようは通常の仮想メモリ管理下にあるページが課金される。 RSSのページはページフォルト時に課金されるけど、すでに課金されてた場合は除く。ページキャッシュはinode(radix-tree)に入れられるときに課金する。プロセスのページテーブルにマップするときは重複して課金しないように気をつけないといけない。

RSSページは完全にunmmapするときに課金した分を減らす。ページキャッシュはradix-treeから削除するときに減らす。unaccountedって日本語でなんて言えばいいか思い浮かばなかった(´・ω・`) もしRSSページがkswapdによってunmapされた場合、SwapCacheとしてシステムによって完全に解放されるまで存在する可能性がある。こういったSwapCacheも課金の対象になる。swapされたページはmapされるまでは課金されない。

カーネルはswap inの先読みや、複数のswapされたページを一度に読みこむんだけど、このときにpage faultが起きる場合があり、この場合は課金しないようにする必要がある。

ページのマイグレーション時には課金の情報はkeepされる。

LRUで管理されるページを課金するのは利用中のページを管理するため。VM視点で行くとLRUで管理していないページはVMの管理外にある。

(´-`).。oO(2.3はまた次回

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス