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]

Please ignore my last previous post as its duplicate to my earlier
post. (I was not aware this thread has been moved from
comp.unix.programmer to here and I thought the post did not get thru).

[ 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 ]

Thanks Don. This answers my question.

[ 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?) ]

Here is our situation, no more than 1GiB of shared memory module size
needed for each client and server process pair. However total pair's
shared memory can go up to 4GiB. The client application is a 32-bits
and the server application is a 64-bits. All the server processes
share another set of shared memory modules among the server processes
that about ~4GiB, hence this has to be 64-bit. As for clients,
migrating to 64-bits causes quite a bit of performance degradation
(~10%).

Therefore, seems like migration to 64-bit and combating performance
issue is the only way to go.