memory limitation in 32-bit HPUX

[Jordan Bean]

I need a definitive answer to this nagging question because various consultants and vendors don't seem to agree or understand.

The environment:
HP9000 K580
HPUX 11.00 32-bit
PA-8200 procs (a waste, I know)

The nag:

I know that processes in 32-bit HPUX cannot address more than 3.75 GB of virtual memory. The remaining 256 MB is reserved for system IO (whatever that means). I'm not concerned about virtual memory...

What I want to know is how much physical memory the HPUX kernel can use... all 4.0 GB possible in 32-bit land? Or is the 3.75 GB ceiling a PA-RISC imposed limitation?

(I know I should upgrade to 64-bit HPUX, but our developers are nervous in a bad way... Meanwhile, we're having to suffer memory pressure during business hours. We have 3.5 GB memory now and an extra 512 MB module to install... Must I upgrade to 64-bit anyway?)

TIA

[Bill Hassell · Accepted solution]

HP-UX 11.0 64 bit is a very old operating system (Nov 1997) yet some people think this is something brand new. Converting from 32 bit to 64 bit operatings system involves less than two dozen files and all 32 bit applications will operate as they did before. There are thousands of customers who have verified this.

3.75 Gb is a kernel mapping limitation in 32 bit mode...nothing changed from 10.xx in that respect. Adding 256 megs will not allow the kernel or processes any additional RAM.

Once the kernel is changed to 64 bit mode (and you can convert back to 32 also), then you have no limitations on the amount of RAM the kernel can address (terabytes..). BUT: your 32 bit programs are still stuck in 3.75 Gb.

There's nothing magic in 64 bit programs: all addresses and offsets must be changed to 64 bits, a non-trivial task in some cases. While compiler options can specify defaults to the 64 bit model, shared memory must be carefully reviewed for potential incompatibilities.

There's one other feature for 46 bit kernels: memory windows. You add lots of RAM, say, 8 Gb for your system. Now 32 bit programs can only address 3.75 Gb (it's more complex than that due to memory quadrants), but it's possible to create separate memory spaces for each program so the entire 3.75 Gb is no longer shared by any other proceses.

Now if processes interact using shared memory, all processes must be started in the same window. The details are covered in detail in the directory: /usr/share/doc. Read the memory management white paper and the memory windows white paper. If the memory windows white paper is not shown, you are likely way behind in patching.

[harry d brown jr]

Jordan,

I "ported" an application from 10.20 to 11i without recompiling a damn thing! This app is written in MicroFocus cobol, C, and C++.

Although your developers do have a legitimate concern, they need to get with the program and move on. And management also needs to understand that they will need to purchase the resources necessary to move forward.

When we move this app into "production", it will be recompiled for 64bit and fully regression tested!



Good luck!!!!


live free or die
harry

[Bill Hassell]

One more thing: Your K580 is a very capable box (64-bit, expandable to many Gb of RAM) but running it in 32 bit mode is essentially crippling the potential of your computer. You may wish to get an inexpensive D-class machine like a D370 or D380 as a test machine, load 64bit HP-UX and start the porting process.

I haven't seen any well-behaved applications have any issues running in a 64bit kernel, and they don't even need to be recompiled unless the programs need 64bit addressing space.

[Jordan Bean]

Oh goodie, a forced upgrade! I'm going to have fun twisting some arms. Thank you both.

[A. Clay Stephenson]

Hi Jordan:

The only real gotcha I've found in porting to 64-bit land occurs in mixed environments accessing common shared memory segments. If a 64-bit process create a shared memory segment but a 32-bit process needs to attach it there can be problems. If this can occur have your developers carefully read the shmget man pages and pay attention to the IPC_SHARE32 section. It they play by the rules everything works fine.

Clay