CODEWITHSUNDEEP
macosmemory-managementcore-graphicsframebufferiokit
pj4533
pj4533

Reputation: 1711

How do I lower the amount of memory IOKit reserves at process start up?

I am a developer working on a very large, memory intensive 32bit application. Running out of virtual address space (memory) is a problem for us. During my investigation of some recent issues I noticed a large chunk of memory that is reserved by IOKit (512MB). This memory isn't allocated, but only reserved. Further investigation showed that most applications (Safari, iTunes etc) all reserve this chunk of memory as well. It seems to stay unallocated. I am using vmmap to test. For example, here is a Cocoa application made with XCode, using the default template:

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

Is there anything I can do to reduce or eliminate that pool of memory? Our application could really use that 512MB!!!

EDIT: I did some more research and it seems that this chunk of memory is the video card framebuffer being mapped into user space. So I guess a more accurate question is if there is anyway to limit framebuffer taking over such a large part of user mode virtual address space?

EDIT: Did some further testing, and found the key that needs to change is IOFBMemorySize. As shown if you do this command:

ioreg -l | grep IOFBMemorySize

Or you can see it in the IORegistryExplorer. I have been unsuccessful in changing that value though. I tried adding it to the Info.plist for the ATIFramebuffer.kext, no good. I tried writing a program that calls IOConnectSetCFProperty, but it returned kIOReturnUnsupported.

EDIT: After more research, seems like this IOFBMemorySize key is likely read only, simply reporting the amount of memory available on the video card. There looked to be some interesting values in the Configuration.plist for CoreGraphics, but none of them seemed to affect the memory allocation (even after a reboot).

Upvotes: 11

Views: 2416

Answers (3)

YAZR
YAZR

Reputation: 89

a. Have you tried running this on a weaker graphic card? So maybe only 128fb will be allocated? Hardware settings for the video card?

b. Use code injection to cancel the memory allocation...

Assuming this is your private app, which doesnt use the framebuff, etc,etc
This is obviously not a single line change, but you can change the code to allocate a smaller buffer, or fail the allocation, or allow the allocation and then release it (and reverse this during program shutdown), etc, etc

I bet this can be done in a stable manner

Upvotes: 0

Grady Player
Grady Player

Reputation: 14549

I think you are looking at this the wrong way.

A) IOKit is not grabbing up 512MB of memory for a Frame buffer.

B) it states in the table that you posted that reserved VM address space (unallocated) so that is probably drive memory that is mapped as a virtual memory space.

C) if you are running out of memory in your running application, you need to structure it differently, examine allocs and leaks, and if necessary perform caching and lazy fetching.

Upvotes: 2

kent
kent

Reputation: 6586

admittedly this is not an answer to your question, but a suggestion on how to continue...

you write that you are working on a very large 32-bit application, so maybe now is the time to re-think your executable architecture and separate the very large application into multiple processes. maybe you want to pack the 32bit specific (QT?) code into one application (be it a background process or GUI driven...) and then put the more memory intensive and processing oriented bits into a secondary (64bit?) application. there are many flavours of inter-process communication to choose from and your app could potentially benefit from a more parallelized architecture.

just an idea... good luck!

|K<

Upvotes: 0

Related Questions