LinuxCon Japan 2012を3倍楽しむための基礎知識

第6回 Linux Kernelメモリ管理最新動向[その2]

この記事を読むのに必要な時間:およそ 4 分

2012年6月6日~8日にLinuxCon Japan 2012 が開催されます。ここではLinux Kernelの最新技術の発表や議論がいろいろ行われるのですが,このカンファレンスを楽しむ手助けとなる記事を…ということで,最近のLinux Kernelのメモリ管理の以下のトピックについて,2回に分けて紹介しています。

第2回目の今回は,以下のテーマについて説明します。

  • ファイルシステム,デバイスと連携したエンハンス
  • メモリ資源管理機能(cgroup)
  • CleanCache

ファイルシステム・デバイスと連携したエンハンス

I/O less dirty throttling

Linuxでは「ファイルシステムに書き戻す必要のあるデータを持ったページ」をdirty pageと呼びます。これらのページはファイルシステムにデータを書くまでは破棄できませんから、メモリ回収前にI/Oを行う必要があります。しかし、I/Oをする際にもメモリが必要になることはよくあります。メモリの大部分がdirtyになってしまうとメモリ回収に悪影響がありますので,Linuxはdirtyページの総数を一定以下に保つようにしています。この一定以下に保つ処理をdirty throttleと呼び,dirty page管理の閾値をdirty limitと呼びます。この処理ではファイル等への書き込みの途中でdirty page量とdirty limitを比較し,dirty page量がdirty limitを超えないように書き込みを抑制します。

以前は,dirty pageの量がdirty limitを超えた場合,limitを超えたthreadが直接「ファイルシステムへの書き戻し」を呼び出していました。そうするとdirty page量が減るまではthreadは実行を止め,アプリケーションも進みません。この書き込みは,I/Oに対する酷い外乱要因となってファイルシステムのパフォーマンスを悪化させるため,アプリケーションが突然遅くなるという問題がありました。

この問題に対し,dirty pageがlimitに近くなった場合,実行中のthreadからは直接にはI/Oを出さないようにする修正がマージされました。新しい dirty throttling ではdirty page の量がシステムに設定されているdirty limitに近づくと,書き込みを行っているthreadの書き込み速度を抑制します(少し寝かせる)⁠

この抑制の仕方がポイントで,今までの実装ではdirty limitになった瞬間に突然遅くなっていた(書き戻しを始めるため)のに対して,新しい実装ではdirty limitに近づくと,徐々に書き込みを行うthreadのスピードが遅くなります。そのため,突然threadがブロックされて大量の書き戻しを開始する処理は無くなり,ファイルシステムへの外乱要因も減るというわけです。

この実装は非常に複雑で,筆者も理解しているとは言い難いのですが,幸いなことに実装者であるWu Fengguang氏(Intel)によるプレゼンテーションが LinuxCon Japan 2012で行われます。ユーザの中でもdirty_ratioをチューニングしている方がいらっしゃると思いますのでこ,の機会に聴講・質問されてみてはいかがでしょうか?

Swap

Swapについてもいくつか話題がありますので,簡単に紹介します。

Swap over NFS, swap over NBD

1つ目は Swap over NFS, Swap over NBD と呼ばれる機能で,Mel Gorman氏(Suse)から提案されています。この機能はネットワーク越しにswap deviceを使えるようにします。Swap Over NFSはswap deviceにNFSを用いたswap,Swap Over NBDはNetwork Block Deviceを用いたswapです。これらの機能はnetworkの先にswapデバイスを作り,メモリ回収の延長でネットワークを使用してリモートマシンにメモリの内容を移します。

Diskless clientでは必要だ,と言われると,そうかもね…という気になるのですが,根本的な問題として,メモリが不足して回収の延長から呼ばれるのに,ネットワーク通信用にメモリを確保しなければいけない点が挙げられますし,モバイル系のシンクライアントでは応答が遅すぎて意味がありません。下手をすると通信用のメモリ確保でデッドロックしますので,Slabアロケータ等にきちんと手を入れて実現する必要があります。現在提案されているものはそのあたりは回避できている,ということですが,提案されてから結構時間が経過しているのに,いまだにマージされるのかどうか見えていません。マージされるには,使いたい人からのアピールやテスト協力等が重要な鍵になりそうです。

Swap over eMMC

2つ目は,フラッシュデバイス上にswapを作った場合の問題があります。Linaroグループの人からの最初の投稿をベースに説明すると,主な問題は,現在のswapの実装がハードディスクを前提としており,フラッシュデバイスの特性とswapの実装がマッチしていないことから生じています。

第1に,swap outが発生する際には4KBずつI/Oが発行されますが,フラッシュデバイスの性能が出るのは32KBや64KBの連続書き込みであるということ。第2はDISCARD(TRIM)サイズの問題です。swapはswap cluster という内部実装を持っていて,このcluster単位でswapエントリの取得等が行われています。このcluster単位を使ってフラッシュデバイスのDISCARD(TRIM)という処理も呼ぶのですが,現在の実装ではclusterの大きさは1MBであり,これが現在の主流のデバイスのDISCARDサイズ,4M/8Mに合っていないというのが彼らの指摘です。

ところでDISCARDとは何でしょうか? フラッシュデバイスには,ウェアレベリング(Ware Leveling)という言葉があります。これは,メモリ素子は書き込みを行うと劣化していくので,1ヵ所に集中して書かずに,できるだけ平準・分散して書き込みを行うことでフラッシュデバイスの寿命を延ばす処理です。この処理のため,フラッシュデバイスは管理しているメモリのうち,どこが使用中でどこがそうではないのかを管理し,ゴミ集め(GC/Garbage Collection)なども行っています。DISCARDは,デバイスに「この部分はもう使ってないよ」と教える処理です。これによりデバイス内部でのGC等がスムーズになりウェアレベリングが楽になります。

これに続く議論の中で指摘されているのが,eMMCデバイスはreadのアクセスレイテンシはwriteよりも圧倒的に低い,だから,write負荷を下げ,read負荷が高くなるようにメモリ回収処理を修正していく方向があるのではないか,というものです。つまり,できる限りcleanなページを追い出し,dirty pageのswap書き込みをできるだけ抑制することでシステム全体の速度を上げられるのではないか?という議論です。今のところ具体的なパッチによる提案等は行われていません。しかし,フラッシュデバイス・不揮発性メモリ関連はこの先しばらくトピックになりそうですね。

著者プロフィール

亀澤寛之(かめざわひろゆき)

静岡県在住のLinuxエンジニアです。現在,memory cgroupのメンテナの一人をつとめており,主にメモリ関連の話題に口を出しています。富士通株式会社のLinuxエンジニアの一人としてサーバシステムの開発やサポートに従事しています。

コメント

コメントの記入