問題タブ [huge-pages]

構成された大きなページのサイズが、JVM に割り当てられたヒープ サイズよりもはるかに大きい JVM 構成を見つけました。

以下に追加した構成は Websphere Application Server 用ですが、ラージ ページを使用する他の Java アプリケーションでも問題は同じです。一般に、IBM JRE では -Xlp ( IBM Knowledge Center - Tuning Linux systems ) スイッチを使用してラージ ページを有効にし、Oracle では -XX:+UseLargePages ( Oracle: Java Support for Large Memory Pages )スイッチを使用して有効にします。

現在の構成が表示されます

また、JVM は -Xlp を有効にして起動します。

vm.nr_hugepages によって 8GB が固定されているため、他のプロセスでは使用できないと思います。しかし、Java はヒープに 6GB しか要求しません。

他の 2GB がどうなるか、誰か説明してもらえますか?

前もって感謝します！

これが私が抱えている問題です：

カーネル ドライバーの rx/tx パケット。ユーザー空間プログラムは、これらの各パケットにアクセスする必要があります。そのため、カーネルとユーザー空間の間で大量のデータ転送が行われます。(データ ストリーム: カーネル rx -> ユーザー空間プロセス -> カーネル tx)

スループットが KPI です。

データのコピーを避けるために、共有メモリ/mmap を使用することにしました。私はそれをテストしていませんが、 tlbがないことが問題になると他の人が言っています。

私が使用しているシステムは、

• mips32系（mips74kc、シングルコア）
• デフォルトのページ サイズ 4KB。
• カーネル 2.6.32

1 つのデータ パケットにのみ収まります。データ変換中に、スループットに影響を与える大量の tlb が失われます。

huge page が解決策になる可能性があることがわかりました。しかし、現在は mips64 のみが hugetlbfs をサポートしているようです。

https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt https://www.linux-mips.org/archives/linux-mips/2009-05/msg00429.html

私の質問は、mips32 で hugetlbfs を使用するにはどうすればよいかということです。または、スループットの問題を解決する他の方法はありますか（ユーザー空間でデータ処理部分を実行する必要があります）

ddaneyのパッチによると、

32 ビット カーネルの PTRS_PER_PTE の値は有効な PageMask を持つことが不可能であるため、現在、パッチは 64 ビット カーネルに対してのみ機能します。ページ割り当てスキームを調整することで、将来的に 32 ビット カーネルがサポートされる可能性があると考えられています。

可能のようです。hugetlb を有効にするために、何を変更する必要があるか、ヒントを教えてください。

ありがとう！

dpdk timer512 個の 2MB hugepages を設定してアプリを実行しようとしましたが、次のエラーでアプリケーションがクラッシュしました

EAL: 4 つの lcore を検出しました

EAL: VFIO サポートを調べています...

バス エラー (コア ダンプ)

hugepagesの数を 256に減らすと、正常に動作します。ここで何が問題なのだろうかと思います。ここに私のCPU情報があります

プロセッサー : 0
vendor_id : GenuineIntel
cpu ファミリー : 6
モデル : 26
モデル名 : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
ステッピング : 5
マイクロコード : 0x11
cpu MHz : 2794.000
キャッシュ サイズ : 8192 KB
物理 ID : 0
兄弟: 4
コア ID: 0
cpu コア: 4
apicid: 0
初期 apicid: 0
fpu: はい
fpu_exception: はい
cpuid レベル: 11
wp: はい
フラグ : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_ perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni destctes pl tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnm i flexpriority ept vpid バグ:
bogomips: 5600.00
clflush サイズ: 64
cache_alignment: 64
アドレス サイズ: 36 ビット物理、48 ビット仮想
電源管理:

プロセッサー : 1
vendor_id : GenuineIntel
cpu ファミリー : 6
モデル : 26 モデル名 : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
ステッピング : 5
マイクロコード : 0x11
cpu MHz : 2794.000
キャッシュ サイズ : 8192 KB
物理 ID : 0
兄弟: 4
コア ID: 1
cpu コア: 4
apicid: 2
初期 apicid: 2
fpu: はい
fpu_exception: はい
cpuid レベル: 11
wp: はい
フラグ : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_ perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni destctes pl tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnm i flexpriority ept vpid バグ:
bogomips: 5600.00
clflush サイズ: 64
cache_alignment: 64
アドレス サイズ: 36 ビット物理、48 ビット仮想
電源管理:

そして、これが私のmeminfoです

MemTotal: 24679608 kB
MemFree: 24014156 kB
MemAvailable: 23950600 kB
Buffers: 3540 kB
Cached: 31436 kB
SwapCached: 0 kB
Active: 21980 kB
Inactive: 22256 kB
Active(anon): 10760 kB Inactive
(anon):
: 11220 kB
非アクティブ (ファイル): 19316 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 32 kB Writeback
: 0 kB
AnonPages: 9252 kB
Mapped: 11912 kB
Shmem: 4448 kB
スラブ：27712
kb sreclaimable：11276 kb
SunReclaim：16436 KB
Kernelstack：2672 KB
Pagetables：1000 KB
NFS_UNSTABLE：0 KB WRITHBAUNCE：0
KB WRITHBACKTMP
：0 KB
COMBITLIMIT：120777660 KB
Commit_As_As
：13792 KB
kb44844848 kB
0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 2048 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 256
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 22000 kB
DirectMap2M: 25133056 kB