Linux memo 2020/10/17

● CMAメモリ領域
CMA(contiguous memory allocator)は、DMAのように使えるメモリ領域を提供するが、そのメモリ領域を普段は通常の用途にも使えるように適合させたLinuxの汎用の仕組み。「MOVABLE」なメモリ割り当て要求のときに限りCMAメモリ領域を渡すようにしておくことで、いざ本当にCMA用途のメモリ割り当て要求が来たときでも、先に渡したメモリ割り当てをmigrateさせて「どかせる」ことで、CMA用途のメモリ割り当て要求にも応えることができるようにしている。
A reworked contiguous memory allocator [LWN.net]
https://lwn.net/Articles/447405/
A deep dive into CMA [LWN.net]
https://lwn.net/Articles/486301/
しかし、実際に使ってみると、そんな理想通りにはなかなかいかない。

● CMAの使いづらさ
Linux の CMA と THP その 1 - コグノスケ
http://www.katsuster.net/index.php?arg_act=cmd_show_diary&arg_date=20170929
より、まさにここで言及されているようなことが起こる。
- 1) THP に CMA 占領されちゃう問題
- 2) ユーザプロセスが CMA 全然使わない問題
それ以外にも、
- 3) cma開放時にpcpリストへ繋がれるためcma以外が空いててもCMAばかり使われ続けてしまう。
- 4) 大量のwriteでdirtyなページキャッシュがたくさんあるケースにて、いざCMAがほしいときにmigrateさせようとするとpage outでディスク書き込みが発生し長時間待たされてしまう
など。最近のLinuxでは改善が入っていたりしていて、1)にはCMA allocでTHPをmigrateさせる変更が、2)にはCMAが使われやすいくする変更が、3)にはpcp入りをやめる提案がされていて(これは結局採用されてない)、などがあるものの、どうも対応にアドホック感がある。ALLOC_CMAをなくす取り組みがrevertされてたりと、正直あるべき姿すらブレていて迷走している。
kswapd0とOOMの発動条件にも悪影響を与えているようで、正直CMAなんてやめて、昔からよくある専用メモリ領域を作って管理したほうが面倒事が少なくて済むように思えてならない。実は誰もCMAをマジメには使っていない?スマホがAndroiでION_HEAPとしてバリバリ使ってるって感じでもないのか?

● OOMの発生しづらさと発生時の予測不能なスラッシングやデッドロック
ケースごとに見ていけばいろいろとあるんだろうけど、下記でXFSにて起こる1例が提示されてる。
The OOM CTF
http://i-love.sakura.ne.jp/The_OOM_CTF.html
FilesystemやディスクI/Oが絡むと「成功してもらわないと困る」メモリアロケーションも多く、そことOOMに選ばれたプロセスへのSIGKILLが重なると、ライブロックや3者間ロックが容易に起こる。以前私がQiitaに書いたこの記事もそんな例の一つになる。
Linux+squashfs+swapなし環境でOOM時にハングする問題 - Qiita
https://qiita.com/rarul/items/843e05a7bc18278e3188
ちなみに、もとのCTF記事中にある「order が 3 以下のメモリ割り当て要求は成功するまで永遠にリトライする」は、PAGE_ALLOC_COSTLY_ORDERのことの模様。上記から言及されてるLWN.netの記事より、
The "too small to fail" memory-allocation rule [LWN.net]
https://lwn.net/Articles/627419/
LinuxのOOMやメモリ管理も、2.6.xやらのころと別物のように変わっているので、OOM発動条件すらが相当理解しにくい。スワップも複雑に絡む。下記の記事も参考に。
スワップの弁護:よくある誤解を解く
https://chrisdown.name/ja/2018/01/02/in-defence-of-swap.html

● ディスクによもsyncが必要な理由
ddコマンドではconv=fsyncなオプションが使えるが、of=がディスクの場合にもこれが必要なことがある。
最近のディスクはハードウェア的なwriteback機能を持っていて、それを積極的に利用するためdisk queueにも非同期で要求を突っ込めるようになっている。
CONFIG_BLK_WBT, QUEUE_FLAG_FUA, QUEUE_FLAG_WC, blk-wbt.c, あたりがキーワードか。

● zlib-ngなど
zlibとのバイナリコンパチと性能改善をうたうzlib-ngというライブラリがある。
https://github.com/zlib-ng/zlib-ng
プロジェクト自体は長く続いているので、適当に採用してもそこそこ使えるだろうと思って試していたら、なんてことはないアプリがクラッシュしやがる。仕方なくいろいろ調べると、arm64のchunkmemset_3()がバグっていることに気づく。報告でもしようかと詳細確認していると、ちょうど直前にchunkmemset_3()とchunkmemset_6()がバグってると削除されてた。プロジェクトがstableバージョンという概念を持ってないようだったので、結局採用するのはやめておいた。
ただまぁ、例えば画像でも、惰性でpngやjpegを使ったりせず、積極的に新しいものを試していかないといけないと思った。opting, zopflipng, brotli, webp, など。webpのlossyで十分だという理由からなのか知らないけど、JPEG 2000は今もほとんど聞かない。
libpng/libzのAPI互換を崩していい(フォーマット互換は維持)なら、minizとかlibspngとかもあるらしい。
https://libspng.org/
これまで何度も宣伝してきたけど、良記事なので、また宣伝しておく。
2016年のOSS圧縮ツール選択カタログ - Qiita
https://qiita.com/nishemon/items/818cc64dc2f8577edd87

このブログ記事について

このページは、らるるが2020年10月17日 18:39に書いたブログ記事です。

ひとつ前のブログ記事は「Linux memo 2020/07/26」です。

次のブログ記事は「Linux memo 2020/11/15 (NEON)」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 5.2.13