メモリフォリオが作成に失敗した後Linux 5.15では、パフォーマンスに影響を与える可能性のあるカーネルメモリ管理コードへのこの低レベルの変更は、Linux5.16に着手しようとしています。
明日すぐに開く可能性のあるLinux5.16マージウィンドウの前に、MatthewWilcoxはカーネルにFolioを導入するためのプルリクエストを送信しました。これは、Folioに慣れていない人、またはこの機能が機能している数か月の詳細を忘れた人のためのプルリクエストからの主な抜粋です。
このチャーンのポイントは次のとおりです。ファイルシステムとページキャッシュがPAGE_SIZEよりも大きなチャンクでメモリを管理できるようにします。当初の計画ではTHPのように複合ページを使用する予定でしたが、ヘッドページのみを期待する関数と、特定のバイトを含む正確なページを期待する関数で問題が発生しました。 Folioタイプを使用すると、関数はヘッドページのみを予期していることを宣言できます。ほぼ偶然にも、これにより、VM_BUG_ON（PageTail（page））およびcompound_head（）へのさまざまな呼び出しを削除できます。
このプルリクエストは、コアMMとページキャッシュの一部のみを変換します。 5.17では、さまざまなファイルシステムを変換し（XFSとAFSの準備ができています。他のファイルシステムでも可能です）、MMとページキャッシュの多くをFolioに変換する予定です。 5.18の場合、複数ページのFolioが用意されている必要があります。
複数ページのFolioは、一部のワークロードにいくつかの改善を提供します。 80％の勝利は本物ですが、人為的なベンチマークのようです（postgresの起動。これは深刻な作業負荷ではありません）。実際のワークロード（カーネルの構築、定常状態でのpostgresの実行など）は、0〜10％のメリットがあるようです。このシリーズの結果としてパフォーマンスが低下したことは聞いたことがありません。深刻なパフォーマンス調整を行った人は誰もいません。先読みアルゴリズムを微調整することで、さらに興味深い成果が得られると思います。 PAGE_SIZEより大きい書き込みなど、大きなFolioを作成することを選択でき、現在は作成できない場所も他にもあります。
エンドユーザーにとっては、パフォーマンス上のメリット以上の可能性があります。後続のカーネルリリースでは、メモリFolioに関する機能が構築されます。
詳細については、