
2025.02.18
「売上をスケールする」AIの使い道とは アルペンが挑む、kintone×生成AIの接客データ活用法
Linuxのhugepageの開発動向(全1記事)
リンクをコピー
記事をブックマーク
堀口直也氏:「Linuxのhugepageの開発動向」について発表します。まず簡単に自己紹介です。私は堀口直也と申します。OSSコミュニティでの開発を軸に技術調査や評価、サポーターに従事しています。これまではカーネルコミュニティで、メモリ管理のコミュニティを中心に10年以上カーネル開発をしてきました。ここ数年はブロックチェーンのHyperledgerプロジェクトにも参加していて、ここでもOSSコミュニティで活動しています。
本日のLT(ライトニングトーク)は最初に「hugepage」の概要を話して、そのあとカーネルコミュニティの開発トピックについて紹介します。
hugepageのアイデア自体はけっこう古くて、70年代ぐらいからあった歴史のあるトピックだそうです。最近重要性が増してきていて、システムのメモリ容量の増大やアプリケーションの巨大化などがその背景にあります。hugepageはTLB(トランスレーション・ルックアサイド・バッファ)の利用効率を上げる機能です。
我々がプログラムを走らせるときには、裏でカーネルが仮想アドレスと物理アドレスの変換処理をずっと行っていて、ページテーブルというツリー構造で仮想・物理のアドレス対応を記録しています。TLBというキャッシュを使って早い道を通るのがキーになります。
ふだんは4段階あるページテーブルをhugepageが3段階や2段階にします。1つのTLBのエントリがカバーする範囲を広く取ることで、うまく使えば広いメモリ範囲を少ないキャッシュミスでアクセスできるのが特徴です。
効果としてはちょっと性能が良くなります。伝統的なSTREAMベンチマークでもスループットが少し良くなります。SpecJVMはワークフローによってバラつきはあるんですが、全体としては数パーセント良くなります。
Linuxにはhugepageに2つの実装があります。hugetlbというものが先に登場したものです。これは専用のメモリプールを作ってそこからプロセスに割り当てる方式です。コードが比較的単純で、動作が予測しやすいです。ですがアプリケーション側でコード対応が必要になります。
後発のtransparent hugepage(thp)はふだん使っているメモリ管理コードを拡張するかたちで実装されています。コードが非常に複雑で予想が難しいんですが、アプリケーションは変更せずに利用できます。おもしろい特徴として、thpは4BKページとthpを相互に変更する操作があります。splitで分解してcollapseでくっつけるという感じですね。
ユースケースで代表的なのは、KVMみたいな仮想化基盤とデータベースですね。どちらも広く使われてはいるんですが、データベース領域では、thpはけっこう嫌われているみたいで、能力があまり発揮できないためオフにされることが多いそうです。これは課題ですね。
概要は以上です。コミュニティの動向ですが、これはKernelnewbiesというまとめサイトから、hugepage関連のトピックを拾ったものです。基本的に使える機能は普通に使えるんですが、日々改善や機能拡張が行われていますね。たくさんあるので全部は紹介しませんが、赤い部分を中心に見ていきたいと思います。ちなみに青いところは私がパッチを書きました。
まず、hugetlbのmin_size mount optionについてです。hugetlbはファイルシステムの形式でマウントして使うんですが、システムのグローバルなプールがあって、そこから割り当てるかたちになっています。普通のファイルシステムと違ってパーティションで区切られていないので、あるマウントでたくさん使い過ぎたら他が使えなくなるんですね。
なのでsubpoolという構造体を用意して、それで上限管理をしています。最近はmin_sizeも指定できるようになって、そのマウントで最低限利用できるページ数を指定できます。設計者はちょっと注意しておくといいかもしれません。
最近話題のトピックで、vmemmap pageの解放があります。これはまだメインラインに入っていないんですが、この発表を準備しているときに見つけておもしろそうだったのでピックアップしてみました。vmemmap pageは何かというと、ページ構造体の配列を格納する領域のことです。ページ構造体は64Bのサイズですが、4KBごとに1つあるので、だいたい1.6パーセントがstruct pageに使われています。これは無駄なので何かできないかと思いました。
実際にhugepageで考えると、例えば2MBのものだと512個のページ構造体があるんですが、8ページ分に詰められているんですね。意味のある使い方がされているのは最初の数ページだけで、このあたりは全部同じ内容です。なのでマッピングをいじって、ここに集約させて残り6ページを解放すれば再利用できます。1GBの場合はもっとたくさん節約できてうれしいですね。
これはけっこう良いなと思っていて、マージされる雰囲気はあったんですが、実はメンテナーから「今のhugepageの解放処理はおかしいよね。まずそこを直せ」とよくあるケチがついて、延期になっちゃいました。
続いてthpのトピックです。page cache supportが重要で、2013、2014年ぐらいからずっと議論されています。従来のthpはanonymous pageに対して使っていたんですが、それを普通のページキャッシュにも使いたいというのは当然の流れです。これはけっこう深いので、スライド1枚で納得のいく説明をするのは無理なんですが、いくつか開発の要点があるので並べてみました。
これはいずれもユーザーには見えないカーネル内の変更なんですが、個人的にはけっこうインパクトがありました。1つ目はスプリットですね。ページのスプリットとマッピングのスプリットを分離しようという話です。今まではスプリットしようとすると、両方とも同時にスプリットせざるを得なかったんですが、それだとちょっとまずいです。
なぜかというと、ページキャッシュはanonymous pageより共有されることが多くて、1つのプロセスがスプリットしたら他は全員に影響を受けちゃうので望ましくないんです。thpとして使うか、4KBページとして使うかをプロセス単位で決めるためにいろいろと実装が変えられて、今はこういうダブルマッピング的なことができます。
ここに絵が描いてあるんですが、1つのthpをpmdにマッピングしつつ他のプロセスからは普通にマッピングできるようになりました。これは1つの進歩でした。他に変更があったのは参照カウントのreworkです。今まで先頭ページが代表していたのを、各サブページでちゃんと参照カウントを取るようになりました。hugetlbを触っていて、一部共有していたコードで僕が昔入れた部分が火を噴いたために巻き込まれた経験がけっこうあったので、この変更は個人的に影響を受けました。
別のトピックです。XArrayというデータ構造があるんですが、ページキャッシュが最近そちらに乗り替わりました。これまではRadix treeを使っていたんですが、そこから新しいものに移りました。重要なトピックがたくさんあるらしいのですが、thpに関係しそうなのがmulti index entryです。
ツリーで各ノードがポインタを持っていて、それでページを指すのですが、thpの場合は複数の幅を持って、インデックスの幅から1つのポインタを指したいときがあります。それができるので効率が良いそうです。
このあたり(ページのsplitとマッピングsplitの分離、参照カウントのrework)は共通部分の改善で、個別のファイルシステムのサポート状況はこんな感じになっています。まだこのあたり(ext4/XFSのサポート)が開発中で、マージされていないのが気になるところです。
次にdefrag optionを紹介します。thpの割り当て要求を出して、それが失敗したときにどうするかという設定なんですが、今まで4つあったものに1つが追加されました。
デフォルトはこのalwaysなんですが、この場合はthpの割り当てに失敗したらその場でちょっとcompactionを試すというものです。そうするとちょっと割り当ての成功率が上がるんですが、遅延が増大します。
それだとよくないという人には別の選択肢もあって、例えばdeferは今回失敗した分についてはおまけしてあげるというものです。4KBページにフォールバックしてあげてもいいけど、裏でページ回収をしたり、compactionを走らせたりすることで、後の割り当て成功率を上げるための悪あがきをする感じですね。neverの場合は、悪あがきはせずに素直に4KBページに落ちます。
この3つと違ってmadviseはアドバイスの切り口が違います。madvise()システムコールでhugepageを使うかどうかを指定ができるんですが、指定したところだけalways相当の動きをして、そうじゃないところはneverにするというalwaysとneverの折衷案みたいな設定です。新しく追加されるdefer+madviseは、alwaysとdeferの折衷案ですね。
あとはいろいろと情報採取を紹介します。thp絡みの情報やhugetlbの情報も新しく追加されています。x86以外も順次サポートを拡張しています。
ということで最後のスライドですが、この発表ではhugepageの概要と最近の開発動向について紹介しました。雑多な内容だったんですが、知っておくと効率の良いアプリケーションを書くうえで助けになるかもしれません。発表は以上です。ありがとうございました。
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07