about shared memory

[Irene Macabio]

Hello Everyone, i'd like to ask :
1) how is the shared memory affect the 32 bit and 64 bit applications?
2) What is the concept of shared memory with this scenarios?
3) How will the shared memory be allocated if i have a 32 bit process/application and 64 bit process/application as well in one box?
4) How will the system manage the sharing of 32 bit and 64 bit application?.
5) Why does the 32 bit only has a maximum of 2GB memory sharing.

Hoping to hear from you, jst wanted to understand it fully well.
Many Thanks!
irene=)

[Arunvijai_4 · Accepted solution]

To see actual shared memory usage,
# ipcs -bmop will help.

1),2),3) and 4) http://devresource.hp.com/drc/STK/docs/refs/3264interop.jsp

5) 32 bit addressing (2 power 32)

-Arun

[Don Morris_1]

[Note: your various questions are intertwined in the answers, so I'm just going to address them in total, not point-by-point].

I don't think "affect" is precisely the word you want here. Shared memory is still shared memory in 32-bit or 64-bit applications, with the caveat that some memory is shared only between 64-bit processes and can not be shared by 32-bit. [Unsurprising since the 64-bit address space is so much larger]. Applications which plan on mixed 32-bit/64-bit sharing on HP-UX must use the MAP_GLOBAL or IPC_GLOBAL flag when creating the shared memory to let the OS know.

Remember how 32-bit processes are laid out as far as the virtual address space (http://docs.hp.com/en/1218/mem_mgt.html for a refresher). There are always 4 1Gb quadrants. The default configuration is for the first quadrant to be for Text/Static Data, the second for Private objects (Heap, Stack, private mmaps) and the last two for Shared Objects (with 256Mb reserved on PA-RISC for I/O mappings). This is what results in the 1.75Gb (PA) or 2GB (IPF) default limit on shared memory for a 32-bit process.

You can use other address space layouts (linker options or chatr) to get more shared address space (moving private to q1 and using q2 for shared -- but only shared with other q2's for 32-bit).

For 64-bit processes (on PA - I don't want to go into the IPF octants right at this moment, but the concept is the same), the first quadrant is shared, with a range just above 4Gb reserved for I/O mappings [note that this is contiguous with the 32-bit I/O mapping range]. There's another shared quadrant as well which is 64-bit only and not terribly germane to our discussion at the moment. As you will note, the 64-bit shared q1 overlays the entire sharable 32-bit space... so now I think you can see how sharing between 32-bit and 64-bit can be managed.

If Memory Windows didn't exist (so that all 32-bit processes used the same shared quadrants), then everything is simple -- any 32-bit shared object is sharable with a 64-bit object. The converse is not true... and so 64-bit shared object creators who intend to share with 32-bit processes must use the MAP_SHARE32/IPC_SHARE32 flag on object creation to let the kernel know that the shared object should be placed below 4Gb in the 64-bit q1 / 32-bit quadrants.

Memory Windows complicates things because the 32-bit shared quadrants may not be the same as the shared 64-bit q1. HP-UX handles this by leaving 32-bit q4 as "global" by default [visible across all processes, even though using Memory Windows]. So PA-RISC has 0.75Gb of shared address space which any process should be able to "see" - since this is a limited resource, the kernel will try to put new objects in other shared quadrants first unless the process uses MAP_GLOBAL/IPC_GLOBAL to specify that they want this object sharable across Memory Windows.

Hope this answers your question.

[Irene Macabio]

Hello Don,Arunvijai,
Thanks Gentlemen....i got what i wanted =).