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: Mon, 17 Nov 2003 00:44:16 -0800
Jim,
Your affirmative answer on mmap() is encouraging. So I will try this and
see how fast it works. I am hoping of course that the setup times will be
much less than the actual transfer times. I will be transferring maybe 20
KB at a time.
I do plan to remap the IO space to physical memory space before each PCI-X
transfer, using IOMapper, as Josh de Cesare described in a posting on
11/12/03. Apparently you make a call to IOMapperInsertPPNPages for each
page you map. I assume this works quickly.
Larry
-----Original Message-----
From: Jim Magee
To: Miller, Larry
Cc: '''email@hidden' ' '
Sent: 11/15/2003 2:35 PM
Subject: Re: Can a task on each of 2 processors share 7 GB of physical m
emory
You would mmap() parts of the file into N different address spaces and
wire them down there to get them all in memory. Then use mmap() in the
two process to map the parts you need to access at any given time.
However, the PCI-X card comment concerns me. Quinn previously asked if
you were wiring because you wanted to do I/O into/out-of the memory and
you said no. But here you talk about I/O. On the current G5 systems,
there is a limit on the amount of memory that can be prepared for I/O
at any given time (so that mappings can be done from the PCI bus
address space to main system memory address). So, you will NOT be able
to access that memory from PCI-X without doing something special for
each I/O.
--Jim
On Nov 14, 2003, at 8:21 PM, Miller, Larry wrote:
>
It is not clear to me that mmap(2) can let a process get a pointer to
a
>
block of physical memory which has been previously wired and contains
>
data
>
that has been loaded oby a PCI-X card.
>
>
It would be good if after suitable initialization, a file descriptor
>
could
>
refer to say a 7 GB file that is mapped entirely into pages in
physical
>
memory. The PCI-X card could load the data into those pages. And
>
then a
>
process on each of the two processord could access whatever part of it
>
they
>
wanted using mmap.
>
>
Is this possible???
>
>
Larry
>
>
>
-----Original Message-----
>
From: Jim Magee [mailto:email@hidden]
>
Sent: Friday, November 14, 2003 4:17 PM
>
To: Miller, Larry
>
Cc: '''email@hidden' ' '
>
Subject: Re: Can a task on each of 2 processors share 7 GB of physical
>
m
>
emory
>
>
>
mmap(2)?
>
>
On Nov 13, 2003, at 11:22 PM, Miller, Larry wrote:
>
>
> 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.
>
_______________________________________________
>
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.