コグノスケ

LinuxのCMAとTHPその2

目次: Android

昨日（2017年9月29日の日記参照）の続きです。各問題への所感です。

THPがCMAを使い切っちゃう問題

THPを諦める、すなわちCONFIG_TRANSPARENT_HUGEPAGEをLinuxのconfigで無効にしてしまえば回避できます。

私の場合THPは無くてもそんなに困らないですから、仮にTHPかCMAの排他的二択がLinuxの現状の仕様だったとしても構いません。

ユーザプロセスがCMA全然使わない問題

今のところ調整方法もへったくれも見つけられず、本当にどうしようもなくて困っています。

Buddy Allocatorを書き換えてMIGRATE_CMAから先にページ割り当てするように改造したところ、ユーザプロセスもドライバもそれなりにご機嫌に動いていますが、魔改造なことこの上ないでしょう。

誰が使ってるのこれ？問題

このデバイスはCMA使ってる、とか、お前の確認方法は間違っているとか、何か知っている人が居たら愚かな私に教えてほしいです……。

Androidデバイスならadbで繋いで /proc/meminfo見たときにCmaFreeって項目があればCMAを使っているはずです。

もしくは古いカーネルだと /proc/buddyinfoにCMAという項目があるかもしれません。

LinuxのCMAとTHPその1

目次: Android

Twitterでボヤきまくっていたけど、流れて消えちゃうのでメモ。Linuxのメモリ管理がさっぱりわかりません。CMA（Contiguous Memory Allocator）とTHP（Transparent Huge Pages）の動きが謎過ぎます。

CMAとは、ある領域を特別な領域として定めて、普段はユーザプロセス用のメモリとして使い、ドライバが要求するなどここぞというときにユーザプロセス用のメモリを強制立ち退き（Page Migration）させてDMA用のメモリとして使う技術です。

私が思いつく利点としては、

• reserved領域などDMA専用のメモリを定義するのに対し
  →ユーザプロセス用のメモリが多く使える
• 通常のカーネルヒープに対し
  →カーネルヒープから物理連続の領域を取得するのは、先客が居たりして難しい（特に大容量の領域ほど）が、CMAならユーザプロセス用のページを立ち退きさせれば良いので比較的容易

THPは仮想連続の4KBのページを512枚集めてきて、2MB（ARMの場合）のHuge Pageに置き換えてしまう技術。のはずです。あまり調べてないので、違ってたらゴメンなさい。

私が思いつく利点としては、

• 4KB 512ページに比べて、ページテーブルの容量が節約できる
• TLBヒット率も上がる、はず

これらの技術のコンセプトは素晴らしいので、ぜひ使いたいと思って使っていますが、動きが謎過ぎて困っています。困っている問題は3つ。

• THPにCMA占領されちゃう問題
• ユーザプロセスがCMA全然使わない問題
• 誰が使ってるのこれ？問題

THPにCMA占領されちゃう問題

THPはkhugepagedというカーネルスレッドが裏でひっそりと活動してページを置き換えます。こいつが使うメモリページはPageCompoundという属性になっていて、なぜかPage Migrationできません。なぜなのか理由はわかりません。

それでいてTHPはCMA領域をガンガン消費します。なぜかはあまり調べていませんが、おそらく、

• 要求する領域のサイズが大きいこと
• 後述するようにユーザプロセスはCMA領域を全然使わないので、CMA領域は比較的空いていること
  ＝連続したページが取りやすい

辺りがCMAから大きいサイズの領域を取りやすい理由だと思います。

しばらく放っておくとCMA領域がTHPで埋まってしまうため、ドライバのdma_alloc() がENOMEMとかで失敗するようになって、ドライバが動かなくなってしまいます。

解決方法を知りたくて、頑張ってBuddy Allocatorまでコード読んでみましたが、khugepagedも結局alloc_pages() でHuge Pageを取っているだけでした。つまり他の用途のメモリの取り方と何ら変わりません。当然ながらCMA領域を避けて取るとか、そんな機構があるようには見えなかったので、この問題を回避する方法はわからないままです。

THPはGFP（Get Free Pages）フラグが少し特殊ですので、Buddy Allocatorでフラグを見てTHPをCMA領域に割り当てないように改造することは出来ましたが、本当にこんな改造が要るんでしょうか？

私が見た範囲では、フラグをチェックしてメモリの割り当て処理を変えている個所は見当たりませんでしたから、何か別の方法が隠れているかもしれません。

誰も困っていないのでしょうか。それとも私の設定がマズいだけでしょうか？

ユーザプロセスがCMA全然使わない問題

Buddy Allocatorの詳細な仕組みはここでは説明しきれませんが、メモリはゾーンという大きな括りで分けられており、各ゾーンには5つのリストがあります。アロケータはこの5つのリストのどれかからページを割り当てます。/proc/pagetypeinfoで各リストの残量を見ることができます。

• MIGRATE_UNMOVABLE
• MIGRATE_MOVABLE
• MIGRATE_RECLAIMABLE
• MIGRATE_HIGHATOMIC
• MIGRATE_CMA

カーネルにメモリページの取得リクエストが来ると、基本的には上4つのリストのどれかからページが取得されます。どのリストになるのかはGFP（Get Free Pages）フラグに何を指定したか？によって決まります。ユーザプロセス用のメモリであればMIGRATE_MOVABLEから取られます。

ではMIGRATE_CMAはいつ使われるのか？というと、これが良くわからないんです。

実機でメモリを使いまくるプロセスを立ち上げ（yes | sortとか）/proc/meminfoの様子を見ていると、

• 空き領域MemFreeが減りまくる（CmaFreeは減らない）
• ページキャッシュCachedが減りまくる（CmaFreeは減らない）
• ページキャッシュがなくなったせいでI/Oが多発してシステムが遅くなる
• やっとCMA領域CmaFreeが減り始める
• OOM Killerにプロセスを強制終了させられる

こんな動きになります。3番目のページキャッシュ減少が起きると、システムが遅すぎて使い物になりませんので、もっと早めにCMA領域を利用していただきたいのですが、なぜかそうなりません。

Buddy Allocatorのコードを見るとMIGRATE_MOVABLEが枯渇というか、ページ割り当てに失敗したときに初めてMIGRATE_CMAからのページ割り当てに挑戦するようになっているように見えます。

個人的にはMIGRATE_CMA → MIGRATE_MOVABLEの順に割り当てた方が良かったのではないか？と思いました。ドライバがCMA領域を使う時はPage Migrationがあるわけですから。

MIGRATE_MOVABLE → MIGRATE_CMAの順に割り当てMIGRATE_MOVABLEを先に使い果たしてしまうと、CMA領域からユーザプロセス用のページをMigrationしようにも移動させる先がありません。これではPage Migrationが役に立ちません。

どうもイマイチです。設定か何かが間違っているのでしょうか。

誰が使ってるのこれ？問題

あまりに訳の分からない動きをしているので、CMAが正常に動いている例が見たかったのですが、手元のAndroidデバイスでCMAを使っているシステムが全くありませんでした。ショック。

CMAは組み込みのように制約の多いハードウェア、かつ、メモリ容量に制限のあるシステム向けの機能です。AndroidであればION Carveout Heapだとメモリ占有が多すぎて耐えられないボンクラハードウェアや、メモリの搭載量が非常に少ないシステム向けの最終兵器のはずです。

GoogleもAOSPで紹介している（Low RAM Configuration | Android Open Source Project のCarveouts, Ion and Contiguous Memory Allocation (CMA) の節）ほどなのになあ。

でも身の回りの製品では誰も使っていません。CMAって誰が使ってるんだろう？？

土曜日＝休日？

今日は土曜日で祝日（秋分の日）です。

サラリーマンや学生は土曜日も祝日も休みという意味では区別がなく、土曜日と祝日が重なると残念な気分になるけれど、当然ながら世の中には土曜日が休みではないお仕事もあります。

我が家に毎週ヤクルトを配達してくれるヤクルトレディーの方に聞いたら、土曜は休みではないが、祝日は休みらしいです。だから先週は休みじゃないけど、今週は配達がお休み。

今まで土曜日と祝日に区別が無くて当然の生活をしていたけど、区別がない仕事と、あるお仕事はどちらが多いのかなあ？

レトロゲーム展示会

JARGA日本レトロゲーム協会の展示会に行ってきました。

日本レトロゲーム協会の展示会ポスター

会場は阪南市の山中の民家です。道が狭く場所が無いので、車で行くとご迷惑になります、というか、なりました……。

展示会では写真に挙げたような、古いゲーム機がたくさん見られます。ファミコン世代は全く知らない70年代のゲーム機も多数あります。

数々の携帯ゲーム

エポック社TV BLOCKとSystem 10

ゲームソフトも大量に所蔵しているそうですが、場所の都合でハードしか置けなかったそうで。

ゲームコーナーもありました。子供もいましたよ。古すぎて見たこと無いはずのゲームを、みなさん楽しそうに遊んでいたのが印象的です。

展示会は無料で見られますが、これだけのもの見せてもらって、タダで帰るのもなあ…、と思って、奥さんと共にJARGAの賛助会員になってみました。

会員になってから知りましたが、JARGAはNPO法人なんですって。会員になった記念？に、JARGA理事長の石井さんが会場を簡単に案内してくれました。

お仕事は中古ゲームショップ経営で、海外旅行が趣味。欧州を半年だか1年だったか掛けて、巡ったこともあるとか。海外ではゲームの博物館があるのに、ゲーム先進国の日本にないのはおかしい、と思ったのが、協会を作った動機だそうです。

将来的には日本橋辺りで博物館を開く予定のようです。しかし日本では博物館は金にならないのも分かっていて、実現できたとしても期間限定だろうとも仰っていました。

文化財に相続税を掛けないようにすれば、節税対策として金持ちが文化財を買い漁って、ついでに綺麗に保管してくれそうなのになあ……。

メモ: 技術系の話はFacebookから転記しておくことにした。