差分

このページの2つのバージョン間の差分を表示します。

--- linux:kernel:cgroup:memory.txt翻訳 [2013/04/03 07:40] – [8.2. 移動するチャージのタイプ] tenforward
+++ linux:kernel:cgroup:memory.txt翻訳 [2013/08/21 15:43] (現在) – [11. メモリプレッシャー] tenforward
@@ 行 1: / 行 1: @@
-<color red>自分用の適当翻訳ですので細かい所は間違いがあると思います．原文をお読みください．</color>
+<color red>自分用の適当翻訳ですので細かい所は間違いがあると思います．原文 (Documentation/cgroups/memory.txt) をお読みください．</color>
+多分，3.10 ベース．
 ====== メモリリソースコントローラ ======
@@ 行 36: / 行 38: @@
   * タスクを移動することによりカウントの移動 (再カウント) が選択可能
   * 使用量のしきい値の通知
+  * メモリプレッシャーの通知
   * oom-killer が knob と oom-notifier を無効にすること
   * root cgroup には制限のコントロールがない
@@ 行 61: / 行 64: @@
  memory.use_hierarchy            # カウントの階層構造の有効/無効を設定する/表示する
  memory.force_empty              # 親グループへチャージを強制移動するトリガ
+ memory.pressure_level           # メモリプレッシャー通知を設定する
  memory.swappiness               # vmscan の swappiness パラメータを設定する/表示する
                                  (See sysctl's vm.swappiness)
@@ 行 458: / 行 462: @@
 ==== 8.3. TODO ====
   * チャージを移動させる全ての操作は cgroup_mutex 配下で実行される．これは，mutex を長時間保持する良くない振るまいである．なので技が少し必要かもしれない．
+===== 9. メモリのしきい値 =====
+メモリ cgroup は cgroup 通知 API (cgroups.txt 参照) を使ったメモリのしきい値を実装している．これにより複数のメモリやmemswのしきい値を登録でき，それが超えた場合に通知を受けとることができる．
+しきい値を登録するには，アプリケーションは以下のようにしなければならない．
+  * eventfd(2) を使って eventfd を作成する
+  * memory.usage_in_bytes か memory.memsw.usage_in_bytes を open する
+  * "<event_fd> <fd of memory.usage_in_bytes> <threshold>" のような文字列を cgroup.event_control に書き込む
+===== 10. OOM コントロール =====
+memory.oom_control ファイルは OOM 通知や他のコントロールを行うためのファイルである．
+メモリ cgroup は cgroup 通知 API (cgroups.txt を参照) を使った OOM 通知を実装している．これにより複数の OOM 通知配送を登録でき，OOM が起こった時に通知を受けとることができる．
+通知を登録するには，アプリケーションは以下のようにしなければならない．
+  * eventfd(2) を使って eventfd を作成する
+  * memory.oom_control ファイルを open する
+  * "<event_fd> <fd of memory.oom_control>" というような文字列を cgroup.event_control に書き込む
+アプリケーションは OOM が起こると eventfd を通して通知を受けとる．OOM 通知は root cgroup では機能しない．
+OOM-killer を無効にするには memory.oom_control ファイルに "1" を書き込む事で可能となる．
+<code>#echo 1 > memory.oom_control</code>
+この操作は階層構造のトップの cgroup でのみ可能である．OOM-killer が無効化された場合，割り当て可能なメモリを要求したとき，cgroup 配下のタスクは，メモリ cgroup の OOM-waitqueue 内でハングアップするかスリープするだろう．
+このようなタスクを実行するには，cgroup の OOM ステータスを以下のように緩和する必要がある．
+  * 制限を大きくするか，使用量を削減する
+  * いくつかのタスクを他のグループに移動させ，アカウンティングも移動させる
+  * いくつかファイルを削減する (tmpfs 上の?)
+そして，タスクを停止させ，再度実行する．
+以下を見ることで，OOM の現在の状態を見ます．
+  * oom_kill_disable 0 or 1 (1 の時，oom-killer は無効化されている)
+  * under_oom 0 or 1 (1 の時，メモリ cgroup は OOM 状態にあり，タスクは停止している可能性がある)
+===== 11. メモリプレッシャー =====
+プレッシャーレベルの通知はメモリアロケーションのコストをモニタリングするのに使う事ができる．これはプレッシャーをもとにしており，アプリケーションは自身のメモリリソースに様々な管理戦略を実装することが可能になる．プレッシャーレベルは以下のように定義される．
+"low" レベルは，システムが新しいアロケーションのためにメモリを回収している事を意味する．この回収の動きをモニタリングする事はキャッシュレベルを良好に保つのに役に立つ可能性がある．通知があると，プログラム (一般的には "アクティビティ・マネージャ") は vmstat を解析し，あらかじめ何らかの動作を行う事が可能になる (例えば，早めに重要でないサービスを停止するなど)．
+"medium" レベルは，システムが中位のメモリプレッシャー状態にあることを意味する．システムは swap し，アクティブなファイルキャッシュをページアウトするなどしている可能性がある．このイベントで，アプリケーションは vmstat/zoneinfo/memcg や，簡単に再構築できたりディスクから再読み込みすれば良い内部的なメモリ使用の統計値と空きリソースのさらなる解析を決定する可能性がある．
+"critical" レベルは，システムが頻繁にスラッシングを起こしている事を意味する．これはまさに out of memory(OOM) しようとしているところであるか，OOM killer が起動しようとしている所である．アプリケーションは，システムを助ける事ができることなら何でもすべきである．この状態では vmstat や他の統計値の状態を見るには遅すぎであり，すぐに何らかのアクションを起こす事が賢明である．
+イベントは，処理されるまで上流に伝搬する．すなわちイベントは貫通はしないということである．これがどういうことかを以下にしめす．例えば，3 つの cgroup A->B->C が存在するとする．さてここで cgroup A, B, C にイベントリスナーを設定し，グループ C がある種のプレッシャー状態にあるとする．この状況で，グループ C のみが通知を受け取る．すなわち A, B は通知を受け取らない．これはメッセージの過度の「ブロードキャスティング」を防ぐためである．過度のブロードキャスティングは，システムの稼働を阻害し，メモリが少なかったりスラッシング状態にある場合に特に悪い影響を与える．なので，cgroup をきちんと構造化したり，イベントを手動で伝搬するようにする (もしくは，パススルーイベントを自分で実装するように求めたり，なぜ必要なのかの説明を求めたりする)．
+memory.pressure_level ファイルは eventfd を設定するためだけに使われる．通知を登録するために，アプリケーションは
+  - eventfd(2) を使って eventfd を作成する
+  - memory.pressure_level を open する
+  - "<event_fd> <fd of memory.pressure_level> <level>" というような文字列を cgroup.event_control に write する
+アプリケーションは，メモリプレッシャーが指定したレベル (か高いレベル) に達した時，eventfd を通して通知を受け取る．memory.pressure_level に対する read/write 操作は実装されていない．
+テスト:
+ここに小さなサンプルスクリプトがある．これは新しい cgroup を作成し，メモリリミットを設定し，cgroup に通知を設定し，それから子供の cgroup に対して深刻なプレッシャーを与えるスクリプトである．
+<code>
+# cd /sys/fs/cgroup/memory/
+# mkdir foo
+# cd foo
+# cgroup_event_listener memory.pressure_level low &
+# echo 8000000 > memory.limit_in_bytes
+# echo 8000000 > memory.memsw.limit_in_bytes
+# echo $$ > tasks
+# dd if=/dev/zero | read x
+</code>
+(多数の通知が予測され，最終的には oom-killer が発動するだろう)
+===== 12. TODO =====
+  - huge ページのアカウンティングサポート (分離したコントローラとして)
+  - cgroup ごとのスキャナーが最初に共有されていないページを回収するようにする
+  - コントローラに共有ページに対するアカウントを教える
+  - 制限には達していないが，使用量が制限に近づいている時に，バックグラウンドで回収を開始する
+===== Summary =====
+全体的に，メモリコントローラは stable なコントローラであり，コミュニティ内で広く議論とコメントがなされてきた
+===== References =====
+  - Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
+  - Singh, Balbir. Memory Controller (RSS Control), \\ http://lwn.net/Articles/222762/
+  - Emelianov, Pavel. Resource controllers based on process cgroups http://lkml.org/lkml/2007/3/6/198
+  - Emelianov, Pavel. RSS controller based on process cgroups (v2) http://lkml.org/lkml/2007/4/9/78
+  - Emelianov, Pavel. RSS controller based on process cgroups (v3) http://lkml.org/lkml/2007/5/30/244
+  - Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/
+  - Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control subsystem (v3), http://lwn.net/Articles/235534/
+  - Singh, Balbir. RSS controller v2 test results (lmbench), http://lkml.org/lkml/2007/5/17/232
+  - Singh, Balbir. RSS controller v2 AIM9 results http://lkml.org/lkml/2007/5/18/1
+  - Singh, Balbir. Memory controller v6 test results, http://lkml.org/lkml/2007/8/19/36
+  - Singh, Balbir. Memory controller introduction (v6), http://lkml.org/lkml/2007/8/17/69
+  - Corbet, Jonathan, Controlling memory use in cgroups, http://lwn.net/Articles/243795/