q3p option

[Satya_6]

Hi,

Is there any disadvantage in using the q3p option? what factors govern the usage of the q3p option? will there be any problem if I build my application with this option and I have less than or equal to 2GB of RAM?

TIA
Satya

[Bill Hassell]

q3p allows an 32 bit application to extend the local data area up to about 2700 megs. Using the option simply sets a flag in the executable and does not occupy any space. If your program starts to allocate local memory, the program can grow to more than 2500 megs if you write the program to do that.

NOTE: 2Gb of RAM is incredibly small to even think about writing programs that use this much RAM. Most of the running programs will be swapped out to make room for your program once your program starts writing into the large area. While HP-UX is a virtual memory OS, it means that massive delays will occur as portions of RAM are written out or read back in order to keep programs running. The average degradation is about 100:1 slower when processes are constantly paging. Use vmstat to see the po (Page Out) rate. 2 digits are not good, 3 digits is awful.

Note also that q3p (and q4p) have minimum OS revision and patch levels.

[Satya_6]

Hi,

thanks for the information.Will there be a bad effect of using the q3p on a machine not meeting the minimum OS revision and patch levels?

Is it really the recommended choice to use q3p or the first step is to play with the maxssiz, maxdsiz and those parameters?

TIA
Satya

[Bill Hassell]

Changing an executable to use q3p has no effect whatsoever except to enable the program to use quadrant 3 for data. But your program cannot use this quadrant until quadrant 1 is enabled (EXEC_MAGIC). Now maxssiz is almost NEVER exceeded in reasonable programs. The stack (maxssiz) is used for parameter passing and return addresses, a few megs at most. When your program makes a call to obtain memory (malloc), it first uses the memory area in quadrant 2 which will max out at about 960 megs (32 bit quadrants are 1000 megs each). If your executable is compiled as an EXEC_MAGIC program, the 1st quadrant can also be combined to get about 1700 megs. Use cc compiler flags -wl -N to create an EXEC_MAGIC program and chatr to show you the resultant program's characteristics.

Now maxdsiz controls the largest amount of data that can be requested. Depending on the age of your HP-UX system, it may be a paltry 64 megs, or as much as 200 megs. Change this to 1800 megs and now your EXEC_MAGIC program can request up to 1800 megs. Note that q3p is a new option, so if chatr does not recognize it, you can't use it.

I have attached an simple program that you can use to see how much RAM can be requested for each of the 5 different program types (for memory allocation).

[A. Clay Stephenson]

The other side of this equation is that nowadays you should really be looking at 64-bit code so that these boundaries are no longer an issue. That would seem to be a much more profitable use of your time rather than fighting 32-bit imposed quadrant boundary issues especially for programs that are all but obsolete out of the box. Your development rules these days is you need small and fast then choose 32-bit options; if there is the slighest chance that you will be approaching memory limits then choose 64-bit.

[Satya_6]

Hi,

thanks again. things are pretty much clear for me now, but I have a couple of last questions.

When I read the man page for ld, I see a statement as "Files of this type cannot be shared" for the -N option. Can you please explain it? I don't understand what would be the implication of this.

Also, when I use the chatr +q3p enable for our executable the application startup time has increased drastically. it takes more than 5 minutes (where it was taking may be 5 - 10 seconds). some debugging showed that it takes time in the call to FlexCheckFeature

Is it the problem because flexlm libs were not compiled or linked with a q3p compatible option?

TIA
satya