maximum value for stack(kbytes) & data(kbytes)

[Ranveer]

Hello guru's
I am having L2000-44 server with 4GB RAM.

#ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 966852
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4194303

Please calrify in this case stack(kbytes) can be increased from 8192 to (4294967296) or tell me what will be the maximum valu for the stack.
& what will be the maximum value for Data(kbytes).

The current kernel value are
maxdsiz 990056448 - 990056448
maxdsiz_64bit 4294967296 - 4294967296

Regds
Ranveer

[Muthukumar_5]

Check this,

http://docs.hp.com/en/B3921-90010/maxdsiz.5.html

hth.

[Muthukumar_5]

For stack,

http://docs.hp.com/en/B2355-60105/maxssiz.5.html

hth.

[Ranveer]

Dear Muthukumar
very thanks for quick reply. Could you please help me in my case. As maxdsize is 990056448 & maxdsize_64bit 4294967296 .

why am i not able to increase data(kbytes)
when ia m trying #ulimit -d 966853
ksh: ulimit: exceeds allowable limit

regds

[Don Morris_1]

Why would you think you would be?

You're trying to set ulimit as follows:


why am i not able to increase data(kbytes)
when ia m trying #ulimit -d 966853
ksh: ulimit: exceeds allowable limit


966853 kb = (966853 * 1024) bytes = 990057472 bytes.

990057472 > 990056448.

So no surprises here.

[Bill Hassell]

The latest patches should fix the problem. Change the maxdsiz value (for 32bit programs) to about 2Gb. NOTE: 32bit programs compiled without special options are limited to about 960megs of data area. For a C program, use the options:

cc -Ae -Wl -N -o myprog myprog.c

This makes your executable an EXEC_MAGIC program, capable of asking for as much as 1700 megs of RAM. There are other options to obtain more RAM for 32bit programs, up to 3700 megs.

[Ranveer]

Hi Don morris
thanks for making the point by correct calculation. still little bit confused...
Point 1. As my OS is 11.11( 64bit) why it is not considering maxdsize_64bit value( 429467294 )
because 99005742< 429467294.

Point 2.Is it possible to set the "data(kbytes)" & "stack(kbytes)" value unlimited. If not what will be the maximum value for the both, with 4GB RAM.
Please help me in clarify the issue.
Regds
ranveer

[Don Morris_1]

Hi Don morris
thanks for making the point by correct calculation. still little bit confused...
Point 1. As my OS is 11.11( 64bit) why it is not considering maxdsize_64bit value( 429467294 )
because 99005742< 429467294.



The OS is 64-bit (otherwise you wouldn't even have the 64-bit tunables), but maxdsiz_64bit is for 64-bit processes. Your shell (or the ulimit program you're using if it isn't part of the shell) is a 32-bit process, evidently. The only time a 64-bit limit affects a 32-bit process is when a 64-bit process forks a 32-bit child, in which case the parent's limits are honored if they're smaller than the system-wide limit. This leads to the odd behavior (since the system process which spawns off shells in the first place is 64-bit) of having a low 64-bit tunable value override the intended 32-bit limit. This isn't happening here since the 64-bit limit is higher.


Point 2.Is it possible to set the "data(kbytes)" & "stack(kbytes)" value unlimited. If not what will be the maximum value for the both, with 4GB RAM.
Please help me in clarify the issue.
Regds
ranveer


Depends on what you mean by "unlimited".

The POSIX standard (I think POSIX set up this interface) defined 32-bit rlimits to have an "Unlimited" value which was RLIM_INFINITY. Unfortunately, the value chosen for that was (2Gb - 1) [32-bit signed integer highest value]. On 64-bit machines, you can actually have >2Gb of data (have to run with at least q3 private, do shared text/data in q0, etc.) -- which leads to some interesting issues.

maxdsiz has a maximum above RLIM_INFINITY, so you could set your data limit to "unlimited" from ulimit's point of view by using that value. You'd still be limited to (2Gb - 1) if you did.

maxssiz has a maximum nowhere near RLIM_INFINITY (maxssiz_64bit just tops the 32-bit value as the maximum, but 64-bit processes have RLIM_INFINITY as the largest 64-bit signed integer, which is much larger), so you wouldn't ever see ulimit report unlimited for that.

Getting back to what I think you really want to know -- no, HP-UX does not support truly unlimited data/stack, especially not for 32-bit processes. For 64-bit processes, there are limits, but they tend to be high enough that well-behaved code never cares (yet!). For 32-bit processes, however, there are several limits that come into play:

1) The rlimit [what you're dealing with]. These are hard limited to the kernel tunables appropriate to the process type (32 or 64 bit) and those tunables have maxima. There is no setting for "unlimited" on the tunables, so there is no true "unlimited" on the rlimit.

2) The quadrants / octants. 32-bit processes run in 4 quadrants in the HP-UX virtual address space layout. The default address space limits private non-text space to 1Gb (this is your heap+bss, stack and any private mmaps, etc. that you have). Therefore, your maxdsiz tunable may be 2Gb -- but if you're running with only the single quadrant, you'll never hit your rlimit anyway. Your heap will grow until it hits the stack or the private mmaps [which start just below the stack and grow towards the heap], no more -- no less.

(2) is important... because the virtual address space for the stack is reserved based on the process's stack limit. Which means that if you set maxssiz very high (to try to have "unlimited" stack) -- you've just taken that much space away from your data. [The converse is not true because data does not pre-reserve any virtual address space].

Hence the recommended behavior (if you don't care about runaway ill-behaved processes starting up and eating all the swap space in reservations for memory leaks or huge mallocs of sparse arrays) is to set maxssiz to something reasonable (8Mb is good for most 32-bit apps, Java or FORTRAN code will likely need more), and only raise it if an application hits the limit -- and you can be reasonably sure it isn't a bug in the application that it did so. Set maxdsiz to the maximum (4Gb - 4096) if that's what you really want... and make sure to raise maxdsiz_64bit to at least that value as well.
This won't make ulimit report "unlimited" -- but it's as good as you can get. Then if your application runs out of private space, look into alternate address space layouts.

Alternately, if what you're trying to run needs that much space and is an in-house application -- look into going 64-bit so you aren't limited to the 4Gb virtual address space in the first place.