1846825 Members
10308 Online
110256 Solutions
New Discussion

32 or 64 bit?

 
SOLVED
Go to solution
Joe Lupo
Occasional Advisor

32 or 64 bit?

I'm trying to get a grasp on 32 vs 64-bit. I was told that "file /path/to/binary" should tell me if the binary is 32 or 64 bit. If it is 32-bit, it'll say:
PA-RISC1.1 shared executable dynamically linked
If it is 64-bit it'll say:
ELF-64 executable object file - PA-RISC 2.0 (LP64)

When I run 'getconf KERNEL_BITS' it says 64 and when I do a 'file /stand/vmunix' it gives me the "ELF..." output from above. But, almost every other binary I check gives me the
"PA-RISC1.1..." output. Does this mean that the OS is 64-bit, but I'm running almost all 32-bit binaries? Does this matter?
7 REPLIES 7
Patrick Wallek
Honored Contributor

Re: 32 or 64 bit?

To see if your OS is really 64 bit do:

# getconf KERNEL_BITS

It will return 32 or 64. The 'file' command will tell you what that particular binary is. A lot of the HP-UX commands are probably 32-bit, which doesn't really matter. Your biggies will be your applications. Without 64-bit you can't take advantage of virtually unlimited shared memory.
James R. Ferguson
Acclaimed Contributor
Solution

Re: 32 or 64 bit?

Hi:

Yes and Maybe (respectively).

Yes, you are running a 64-bit kernel. Both 'getconf' and 'file /stand/vmunix' tell you that. Yes, too, your binaries are 32-bit ones.

No, running 32-bit binaries in a 64-bit environment isn't the end of the world. Obviously, they can't address large amounts of memory, and if its Oracle, for instance, you are seriously constraining yourself in terms of the SGA size you can have!

Remember taht the kernel parameters 'maxdsiz', 'maxssiz' and 'maxtsiz' operate for 32-bit binaries whereas the same parameters suffixed with "_64bit" apply to 64-bit ones.

Regards!

...JRF...
Steven E. Protter
Exalted Contributor

Re: 32 or 64 bit?

32 and 64 bit binaries can coexist, so long as the 32 bit ones are certified to run on the 64 bit OS. There may be a performance difference.

We run Oracle 64 bit EE database server and 9ias Application server from Oracle. They work fine together.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Joe Lupo
Occasional Advisor

Re: 32 or 64 bit?

Well, our applications have been running, but we've been getting this shmget errno 12 message recently. So, I'm just trying to do a bit of research to understand what I'm looking at.
The one binary that is causing this error is 32-bit, but the vendor has been claiming that it is 64.

Anyway... if they are 32-bit, what is the limit for shared memory? and how does it work? I think I read somewhere that it is 1.75Gb. We have our shmmax kernel param set to 15000000000 (approx 15Gb) and we have 16Gb of physical memory. Does this mean that 32-bit apps can only access the first 1.75Gb of shared memory? And, if there is not a segment large enough to fit the apps request within that first 1.75Gb, then it fails?

Thank you all for your assistance.
Gary Yu
Super Advisor

Re: 32 or 64 bit?

I guess memory window maybe a solution, although haven't implemented myself.

thanks,
Gary
Steven E. Protter
Exalted Contributor

Re: 32 or 64 bit?

The 64 bit app can address more memory as you say.

You are also correct in saying that you can have two different 32 bit apps, one will work on 64 bit HP-UX, the other will not.

Your research will lead you back to the application vendor eventually.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
James R. Ferguson
Acclaimed Contributor

Re: 32 or 64 bit?

Hi (again) Joe:

Yes, the limit for shared memory (SMHMAX) is 0x40000000 or about 1GB in decimal for 32bit applications. Memory Windows would extend that, but you really need the 64-bit environment addressing!

See here:

http://docs.hp.com/hpux/onlinedocs/939/KCParms/KCparams.OverviewAll.html

Regards!

...JRF...