RE: Can a task on each of 2 processors share 7 GB of physical m emory
RE: Can a task on each of 2 processors share 7 GB of physical m emory
- Subject: RE: Can a task on each of 2 processors share 7 GB of physical m emory
- From: "Miller, Larry" <email@hidden>
- Date: Thu, 13 Nov 2003 20:22:52 -0800
Jim,
What would be an efficient remapping technique so a given task can quickly
get a window into a desired part of the physical memory?
Larry
-----Original Message-----
From: Jim Magee
To: Miller, Larry
Cc: ''email@hidden' '
Sent: 11/13/2003 5:37 PM
Subject: Re: Can a task on each of 2 processors share 7 GB of physical m
emory
On Nov 13, 2003, at 11:58 AM, Miller, Larry wrote:
>
By wired, I mean the data that I put in the memory remains at a fixed
>
place
>
in physical memory - it is not paged out. This would probably be
>
equivalent
>
to a fixed mapping from VM to physical memory.
Then you probably could simultaneously wire 7GB out of 8GB physical as
you request.
>
I heard that OS-X Panther was in some ways a 64-bit OS. In other
>
words, I
>
thought tasks could execute 64-bit addressing load and store machine
>
instructions. Maybe I am mistaken.
>
>
Also, I maybe mistakenly thought that you could compile a C/C++
>
program in a
>
way such that you could have 64-bit pointers that are dereferenced.
There are lots of things that define a 64-bit support. Using 64-bit
addresses to access >4GB of mapped virtual memory in a single task is
only one (maybe two - depends upon how you count) such feature (which
happens to be absent in Panther/Darwin 7.x). The ability to access
>
4GB of physical of physical memory in the first place is also one. An
additional feature is the ability to access and use 64-bit wide
registers in critical functions (and have the kernel preserve that
state correctly on interrupts/signals, etc...). These last two ARE in
Darwin 7.x.
>
If these things are not available, does anyone one have an idea of
>
when they
>
will become available in the future?
As always, we can't make any statements about future Mac OS X plans
here or elsewhere. But from a technology point of view, it is
down-right inevitable that 64-bit address space support will make it
into Darwin - eventually.
In the meantime, using multiple address spaces to wire the memory down
in, and (re)mapping techniques to gain access to some percentage of the
memory at any given time, should work. For most applications, this
should be acceptable (performance-wise). It's the cost of getting stuff
in and out of physical memory that is the real bottleneck. At first
reading, this seems to fit well with the "up to 256MB chunk" model of
memory allocation you suggested earlier.
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.