Re: HP-UX Shared memory windows in mixed mode

[Database Administrator]

On Nov 7, 10:31*pm, Don Morris wrote:
> nkravi wrote:
> > Hi,
>
> > This question is targeting on HP-UX B11.11 (pa risc 2.0) shared memory
> > memory windowing in mixed mode (32-bit application and 64-bit
> > application) environment.
>
> I think you'd be better off asking in comp.sys.hp.hpux. Followups set.


My apologies, however from my past encounters, programming related
posts in that thread always gone unnoticed
Sure, next time I will post there first.

>
> > I notice an issue when 32-bit application acquires a shared memory
> > segment under memory windows and 64-bit application tries to attach to
> > it.
>
> As one would expect -- 64-bit applications share the Global (Memory
> Window 0) 32-bit window with 32-bit applications. You have to use
> IPC_GLOBAL to put the segment (if it fits) in the Global Q4 window
> which both the 32-bit Memory Windows app and the 64-bit apps will see
> (man 2 shmget, man 1M setmemwindow, Memory Windows White Paper, etc.)
>

By specifying IPC_GLOBAL, the share memory module will get push to Q4
of 32-bit applications which is out of windowing. therefore IPC_GLOBAL
pretty much defeat the purpose of achieving more than 1.75G total
shared memory.

> > Attached below is the sample code and the error information from the
> > run.
>
> snipped -- this would be entirely expected (you could get lucky and
> end up in Q4 if the Window Q2/Q3 is full... but that's unreliable).
>
>
>
> > This gives me an impression that 64-bit application do not able to
> > 'see' 32-bit application windowing on Q3. Is there any way to get
> > around this?
>
> Use IPC_GLOBAL as indicated.
>

So i assume shared memory windowing are implemented solely for 32-bits
application and 64-bits application do not support it in mix mode.

I believe the fact that 64-bit address space quadrants where reordered
(Q1 for shared object instead of Q3 as in 32-bits) was to support
shared object to be shared in mix mode. However seems like shared
memory windows design has left out this mix mode scenarios.


> Don
> --
> kernel, n:
> A part of an operating system that preserves the medieval traditions
> of sorcery and black art.

Thanks.

[Database Administrator]

nkravi wrote:
> On Nov 7, 10:31 pm, Don Morris wrote:
>> nkravi wrote:
>>> I notice an issue when 32-bit application acquires a shared memory
>>> segment under memory windows and 64-bit application tries to attach to
>>> it.
>> As one would expect -- 64-bit applications share the Global (Memory
>> Window 0) 32-bit window with 32-bit applications. You have to use
>> IPC_GLOBAL to put the segment (if it fits) in the Global Q4 window
>> which both the 32-bit Memory Windows app and the 64-bit apps will see
>> (man 2 shmget, man 1M setmemwindow, Memory Windows White Paper, etc.)
>>
>
> By specifying IPC_GLOBAL, the share memory module will get push to Q4
> of 32-bit applications which is out of windowing. therefore IPC_GLOBAL
> pretty much defeat the purpose of achieving more than 1.75G total
> shared memory.

It is a trade off. The 32-bit apps within each window can have more than
1.75Gb of total shared memory with each other -- but only up to 1Gb of
that can be shared with 32-bit processes in *other* windows or with
64-bit processes [which are *always* viewing Memory Window 0].

>
>>> Attached below is the sample code and the error information from the
>>> run.
>> snipped -- this would be entirely expected (you could get lucky and
>> end up in Q4 if the Window Q2/Q3 is full... but that's unreliable).
>>
>>
>>
>>> This gives me an impression that 64-bit application do not able to
>>> 'see' 32-bit application windowing on Q3. Is there any way to get
>>> around this?
>> Use IPC_GLOBAL as indicated.
>>
>
> So i assume shared memory windowing are implemented solely for 32-bits
> application and 64-bits application do not support it in mix mode.

64-bit applications support sharing with Memory Windows applications
just fine -- it is simply that they are always in Memory Window 0 for
their 32-bit shared space. And this can not be changed.

>
> I believe the fact that 64-bit address space quadrants where reordered
> (Q1 for shared object instead of Q3 as in 32-bits) was to support
> shared object to be shared in mix mode. However seems like shared
> memory windows design has left out this mix mode scenarios.
>

No -- the design allows for the scenario by keeping the 64-bit apps
in Window 0. Trying to have only the low Gb ranges of 64-bit Q0 in
different windows (or somehow allowing 64-bit applications to see
"all" 32-bit windows) is quite simply impossible on PA-RISC, hence
it wasn't done. It might be possible on IPF since the 64-bit addresses
could be aliased -- but then you might as well use MPAS.

If you really need more than 1.75Gb of shared object space *and* need
to share with one or more 64-bit applications -- I'd really think your
real solution is just to go fully 64-bit already. Memory Windows is a
stopgap (what happens when you need more than 2.75Gb of shared
objects next?)

Don