Memory requirements and kmtune parameters

[kiran bachu]

Hi,
I am dealing with a customer where my binary is 32bit on 64bit HP OS with 3GB RAM. Our binary failed bcos of "out of memory" while mallocing, then I told them to set kmtune parameters such as maxdsize,maxssize,maxtsize,etc. Then it went successfully thru.
Again they came back and said it still shows out of memory error. They say that 32bit application cannot use more than 1GB of memory even if RAM is of 3GB.

In one of the docs in techinical resources, it is mentioned that the 32bit application can have 4GB memory. What is the role of kmtune parameters as well?

Can some one please explain me clearly how to use the memory available? This is very urgent.

I appreciate the quick response.

thanks
kiran

[Sandip Ghosh]

You are right.
32bit Application can acceess max 4GB memory, precisely 3.75 GB. Better you increase the memory and increase the shared memory (shmmax) in the kernel. I think this will solve your problem.

Sandip

[Kirby Collins]

to allocate more than 1GB of data in a 32-bit program, you need to increase the value of the kernel parameter maxdsiz, plus link the program -N (to allow it to use both the text and data segments for heap).

for more details, see ld(1).

[kiran bachu]

Thanks all for the quick response!!
I already tried giving kmtune parameters values to the customer.
We don't link with -N option. Do you think this would help?
Does shmmax value also play any role besides maxdsiz?

Customer is claiming that even if he buys more memory, it doesn't make any sense bcos hp support has told him that 32bit app cannot use more than 1GB.

I am trying to gather more info in order to satisfy his needs.

That's true VM is for using more than available mem. My binary can allocate memory at once which could be more than 1GB, I don't think swap space would be utilized here.

Any more comments on this?
thanks
kira

[Bill Hassell]

It's very important to read the white papers in /usr/share/doc on proc_mgt and mem_mgt. The allocation of RAM in a 32bit program is severely restricted. The kernel parameters are simply program protection fences. Changing maxdsiz (the only one that affects malloc calls) will allow the program to grow up to that value, but it is certainly possible to set maxdsiz much larger than the program can request.

Linked with no quadrant mapping options, a program can only malloc about 950 megs, no matter how large maxdsiz might be. Change the executable with the -N option and now the text quadrant and data quadrant can be used together for a total of up to 1.9 Gb. This called an EXEC_MAGIC executable.

64bit executables have no practical limit on memory addressing (well, terabytes...)

As far as RAM, if you run 5 copies of the program and each requests 900 megs of RAM, you will severely exceed the amount of RAM and programs will page out, which is not a problem of performance is not of concern. Physical RAM in HP-UX is only important when processes start paging out. The actual memory for all processes is a function of RAM plus swap space. It is quite possible to run a 900 meg program in 128 megs of RAM. The only downside is that the program may experience up to a 100:1 degradation in performance. In a 3Gb system, assuming nothing else significant is running, malloc'ing 1500 megs of RAM should not cause any paging.