コグノスケ

黄色いナンバープレートは嫌われている？

目次: 車

軽の黄色がこれほど不人気とは…白地の五輪ナンバー人気: 朝日新聞デジタル を読んで。

「黄色が車の色と合わなくて嫌」ならわかるけど「軽だとすぐわかって格好悪いから嫌」って意味分かりません。なんで軽が格好悪いんでしょう？百歩譲って主張の通りだとしても、ナンバー白くして何か解決するのか？

予想

コメントにて「トヨタをレクサスに張り替えるような、エンブレム張り替えと同じではないか？」という突っ込みをいただきました。

なるほど、高い車に乗っている気分を出したいんでしょうか？個人的には軽自動車とコンパクトカー（普通自動車）はあまり値段が変わらないから、見栄になっていないように思いましたが、乗っている本人の気持ち次第ですね……。

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

スマホが壊れた

スマホ（ASUS Zenfone 3 Deluxe ZS550KL）を家の床に落としたら、電源ボタンが凹んでしまって、押せなくなってしまった。困った。

音量調整ボタン（左）は無事、電源ボタン（右）は帰らぬ人に

スリープからの復帰は、背面の指紋認証があるから問題ないけれど、スリープへの移行が出来ない。

画面が粉々なら諦めて買い換えるけど、電源ボタン以外は全く問題ないので、買い換えるほどでもない…でも不便……。

メモ: 技術系の話はFacebookから転記しておくことにした。後日、写真を追加した。

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って誰が使ってるんだろう？？