問題タブ [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.
c - カーネル ドライバーでの hugepage への順次アクセス
hugepages に裏打ちされたバッファーを使用するドライバーで作業していますが、hugepages の連続性に問題があることがわかりました。
mmapユーザー空間では、プログラムはsyscallを使用して hugepages に裏打ちされた大きなバッファーを割り当てます。バッファーは、呼び出しを介してドライバーに伝達されioctlます。ドライバーはget_user_pages関数を使用して、そのバッファーのメモリ アドレスを取得します。
これは、1 GB (1 hugepage) のバッファー サイズで完全に機能します。get_user_pages多くのページ ( HUGE_PAGE_SIZE / PAGE_SIZE) が返されますが、それらはすべて連続しているため、問題はありません。最初のページのアドレスを取得して、それを操作page_addressします。remap_pfn_rangeドライバーは、別のプログラムがmmapchar デバイスで呼び出しを行うときに、そのバッファーをユーザー空間にマップすることもできます。
ただし、バッファが複数の hugepage に支えられている場合、事態は複雑になります。カーネルは、非シーケンシャルな hugepage に裏打ちされたバッファーを返すことができるようです。つまり、hugepage プールのレイアウトがこのようなものである場合
HP1 と HP4、または HP3 と HP2 を予約することで、hugepage でバックアップされたバッファーの要求を満たすことができます。つまりget_user_pages、最後のケースでページを取得すると、ページ 0 のアドレスは実際にはページ 262.144 (次の hugepage の先頭) のアドレスの 1 GB 後になります。
これらのページへのアクセスを順次処理する方法はありますか? バッファ全体を使用できるように、アドレスを並べ替えて下位のアドレスを見つけようとしました（たとえば、カーネルが HP3、HP2 に基づくバッファを提供する場合、HP2 のアドレスをベース アドレスとして使用します）が、データがスクランブルされるようです。ユーザー空間（その並べ替えられたバッファーのオフセット0は、ユーザー空間バッファーのオフセット1GBの可能性があります）。
TL;DR: 順序付けられていないヒュージページが 1 つ以上ある場合、Linux カーネル ドライバーで順番にアクセスする方法はありますか?
ところで、私は 3.8.0-29-generic カーネルを搭載した Linux マシンで作業しています。
c++ - malloc() による割り当てがヒュージ ページによってサポートされているかどうかを判断する
透明な hugepageがどのように機能するか、およびによって実行される割り当てなどの割り当てmallocが huge page によって満たされる可能性があることをよく理解しています。
私が知りたいのは、メモリが巨大なページに支えられているかどうかを判断するために、割り当て後に（おそらくヒューリスティックに）できるチェックがあるかどうかです。
memory-management - SYSFS 経由で nr_hugepages を設定中にエラーが発生しました
8G の物理メモリ (Fedora20) があり、次のパラメーターをカーネルに渡すことで、起動時に 2 つの 1G hugepage を割り当てるようにカーネル パラメーターを構成しました。
HugeTLBFS は自動マウントされます。
再起動すると、すべて問題なく表示され、カーネルが必要なページを割り当てていることがわかります。
ご覧のとおり、空きメモリの量により、ヒュージページの数を増やすことができるはずですが、そうすることができません:
また
ページ数を減らすことも失敗します。私は何を間違っていますか？
performance - 巨大なページを利用するように Prolog プロセッサにアドバイスする
通常の 4Kb メモリ ページの代わりにヒュージ ページ (メモリ ページあたり 2MB/4MB) の利用をサポートする Prolog 実装はありますか。
理想的には、インタプリタ/コンパイラ/ランタイムに対して、特定のアプリケーションのさまざまなヒープ/スタック/スクラッチパッド メモリに X huge-pages を使用しても問題ないことを宣言したいと思います。
もちろん、すべてのアプリケーションがこの恩恵を受けるわけではありませんが、恩恵を受けるアプリケーションは少なくないと確信しています。結局、メガバイトは新しいキロバイトです:)
c - 巨大なページに mmap と madvise を使用する
Linux マシンで使用されているヒュージページにメモリを割り当てたいと考えています。mmapこれを行うには、とを使用する 2 つの方法があることがわかりますmadvise。
つまり、呼び出しでMAP_HUGETLBフラグを使用する -mmap
そして、コールのMADV_HUGEPAGEフラグ-madvise
誰かが2つの違いを説明できますか?
c - ページテーブルをダンプするには?
私はLinux、C、およびスタックオーバーフローが初めてです。実行中のすべてのプロセスのページ テーブルを表示しようとしていました。このために、私はdump_pagetable.cを使用しています。
まずは通常のコンパイルで実行してみましたgcc dump_pagetables.c -o dump_pagetables.out。しかし、それは私にエラーを与えました:
- このコードを実行するにはどうすればよいですか?
dump_pagetables.c巨大なページも表示できるように変更するにはどうすればよいですか。