11

私は非常に大規模なメモリ集約型の 32 ビット アプリケーションに取り組んでいる開発者です。仮想アドレス空間 (メモリ) の不足は私たちにとって問題です。最近の問題の調査中に、IOKit (512MB) によって予約されている大きなメモリ チャンクがあることに気付きました。このメモリは割り当てられておらず、予約されているだけです。さらに調査したところ、ほとんどのアプリケーション (Safari、iTunes など) もすべて、このメモリのチャンクを予約していることがわかりました。未割り当てのままのようです。vmmap を使用してテストしています。たとえば、デフォルトのテンプレートを使用して、XCode で作成された Cocoa アプリケーションを次に示します。

REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  1008K
CG image                              4K
CG raster data                       64K
CG shared images                   2252K
Carbon                             7264K
CoreGraphics                         16K
IOKit (reserved)                  512.0M        reserved VM address space (unallocated)
MALLOC                             59.0M        see MALLOC ZONE table below
MALLOC guard page                    48K
MALLOC metadata                     348K
Memory tag=242                       12K
STACK GUARD                        56.0M
Stack                              8712K
VM_ALLOCATE                        16.2M
__DATA                             8296K
__IMAGE                            1240K
__LINKEDIT                         31.5M
__TEXT                             76.7M
__UNICODE                           536K
mapped file                        27.4M
shared memory                      1320K
===========                      =======
TOTAL                             809.2M
TOTAL, minus reserved VM space    297.2M

そのメモリのプールを削減または排除するためにできることはありますか? 私たちのアプリケーションは実際にその 512MB を使用できます!!!

編集：さらに調査を行ったところ、このメモリのチャンクは、ユーザー空間にマップされているビデオ カードのフレーム バッファであるようです。したがって、より正確な質問は、ユーザーモードの仮想アドレス空間の大部分を占めるフレームバッファーを制限する方法があるかどうかだと思いますか?

編集: さらにテストを行ったところ、変更が必要なキーは IFBMemorySize であることがわかりました。次のコマンドを実行すると、次のようになります。

ioreg -l | grep IOFBMemorySize

または、IORegistryExplorer で確認できます。ただし、その値を変更することに失敗しました。ATIFramebuffer.kext の Info.plist に追加しようとしましたが、ダメです。IOConnectSetCFProperty を呼び出すプログラムを作成しようとしましたが、kIOReturnUnsupported が返されました。

編集: さらに調査した結果、この IOFBMemorySize キーは読み取り専用である可能性が高く、単にビデオ カードで使用可能なメモリの量を報告しているようです。CoreGraphics の Configuration.plist には興味深い値がいくつかあるように見えましたが、メモリ割り当てに影響を与えるものはありませんでした (再起動後でも)。

4

3 に答える 3

2

あなたはこれを間違った方法で見ていると思います。

A) IOKit がフレーム バッファ用に 512MB のメモリを使用していません。

B）あなたが投稿した表に記載されているreserved VM address space (unallocated)ので、おそらく仮想メモリ空​​間としてマップされているドライブメモリです。

C) 実行中のアプリケーションでメモリが不足している場合は、アプリケーションを別の方法で構造化し、割り当てとリークを調べ、必要に応じてキャッシュと遅延フェッチを実行する必要があります。

于 2011-07-03T22:57:30.777 に答える
0

確かに、これはあなたの質問に対する答えではありませんが、続行する方法についての提案です...

あなたは非常に大きな 32 ビット アプリケーションで作業していると書いているので、おそらく今こそ、実行可能なアーキテクチャを再考し、非常に大きなアプリケーションを複数のプロセスに分割するときです。32 ビット固有 (QT?) コードを 1 つのアプリケーション (バックグラウンド プロセスまたは GUI 駆動型) にパックし、よりメモリ集約型で処理指向のビットをセカンダリ (64 ビット?) アプリケーションに入れたいと思うかもしれません。選択できるプロセス間通信には多くの種類があり、アプリはより並列化されたアーキテクチャから利益を得る可能性があります。

ただのアイデア...頑張ってください！

|K<

于 2011-07-07T09:47:40.153 に答える
0

を。これを弱いグラフィックカードで実行してみましたか? では、128fb だけが割り当てられるのではないでしょうか? ビデオカードのハードウェア設定？

b. コード インジェクションを使用してメモリ割り当てをキャンセルします...

これがフレームバフなどを使用しないプライベートアプリであると仮定すると、
これは明らかに単一行の変更ではありませんが、コードを変更して、より小さなバッファーを割り当てるか、割り当てに失敗するか、割り当てを許可してから解放することができます（そしてプログラムのシャットダウン中にこれを逆にします）など

これで安定していけそうです

于 2011-07-20T08:43:25.767 に答える