Re: Problem using .zerofill / -segaddr to create very large segments
Re: Problem using .zerofill / -segaddr to create very large segments
- Subject: Re: Problem using .zerofill / -segaddr to create very large segments
- From: Terry Lambert <email@hidden>
- Date: Tue, 22 Sep 2009 12:21:53 -0700
On Sep 22, 2009, at 3:35 AM, Alastair Houghton <email@hidden
> wrote:
On 22 Sep 2009, at 11:19, Jay Reynolds Freeman wrote:
> I assume, given the above, that the motivation for this is that
> you're trying to set things up such that pointers in the shared
> memory all have the same addresses in each of the processes, and
> that means you want to reserve the same block of address space
> no matter what.
Correct.
Have you tried using the "vmmap" tool to investigate the virtual
memory map of the process that you're having trouble with? That
should enable you to investigate where the free regions of VM are
likely to be at the correct point in your program's execution.
I'm not sure what the precise virtual address space limits are for
OS X---there's probably a tech. note somewhere, but someone here
will know in any case---but it should be easy enough to locate a
region that's large enough for your purposes.
Kind regards,
Alastair.
There is an architectural limit of 48 bits on Intel processors, which
is documented, well, pretty much everywhere anyone who is doing code
generation is looking at Intel documentation.
That's 2^16 * 2^32 = 64K *4GB = 256TB.
So I'm pretty sure your approach of finding a large hole in the middle
of the available virtual address space and just using it for a fixed
mapping will work fine. I definitely would NOT put the hole in the
heap using static allocations to get mapping set up by the kernel
image loader, whose job is really to get something (hopefully not a
huge amount of that something) into memory rather crudely, then hand
over control to dyld to do the rest.
That said, unless you have a metric ton of memory, mapping 320GB into
your address space will take a lot of wired pages to represent the
pmap and other data structures needed to provide the mapping for that
many pages, so I probably would not be trying this on a machine with a
32 bit kernel and a lot of physical RAM.
320GB / 1 page per 4MB stride for a 64 bit pmap works out to 80K pages
of page mappings, or 320MB not counting other overhead: a good
argument for mapping windows instead of direct mapping everything.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden