問題タブ [huge-pages]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
linux - VirtualBox は OS 固有の「巨大なページ」を割り当てますか?
大量の RAM を搭載した VirtualBox と VM を使用すると、重大なパフォーマンスの問題に苦しんでいます。これについては、既に他の質問で詳しく説明しています。これまでにテストしたことから、VM に割り当てられたメモリの量には直接的な関係があります。問題は 48 GB の RAM で発生し、6 GB のみlargepagesでも VM の設定を有効にしても発生しません。
興味深いことに、その設定はLinuxではデフォルトで有効にされていないようです。ドキュメントでは、約 5% の改善についてしか説明されておらず、一部の RAM サイズで適切なパフォーマンスを得るためにはまったく必要ではなく、さらに次のような状況もあります。 VirtualBox では完全にlargepages無視されます。
00:00:42.866663 PGMR3PhysAllocateLargePage: 大きなページの割り当てに時間がかかりすぎます (最後の試行 103 ミリ秒; タイムアウト数 11); 無効にする
https://www.virtualbox.org/attachment/ticket/16518/VBox_16518_5112.log#L1154
そこで、その機能がVirtualBoxのメモリ管理で実際にどのような変化をもたらすのかを掘り下げてみたところ、OSの「ヒュージページ」に匹敵する仕組みを単体で実装しているように見えるという結論に達しました。つまり、私の意見では、どのような種類の「巨大なページ」も割り当てずtransparent、hugetlb*OS から 4 kB のページのみを取得し、それらを 2 MB のチャンクに結合し、それを内部で1 つの論理ページとして使用します。
私のパフォーマンスの問題に関しては、（メモリ管理）パフォーマンスの違いは、ホストOSの最適化ではなく、VirtualBox自体からのみ発生する可能性があることを意味します。OTOH、VirtualBoxが「ヒュージページ」に似たアプローチを実装する場合、OSの「ヒュージページ」を使用する他のソフトウェアと同様に、私の場合にパフォーマンス上の利点が見られる理由を説明するかもしれませんmadvise. 私の場合--largepagesのように本当に大きな違いがある場合は、VM である程度の RAM の設定を必要としない VirtualBox のバグであると主張することさえできます。
では、VirtualBox が特別な巨大なページではなく、OS からプレーンな 4 kB ページのみを使用するという私の仮定は正しいでしょうか?
VBox/VMM/VMMR0/PGMR0.cpp:
VBox/VMM/VMMR0/GMMR0.cpp:
VBox/Runtime/r0drv/linux/memobj-r0drv-linux.c: