On 08/10/2012 06:33 PM, Vijay Sankar wrote:
Quoting Friedrich Locke <friedrich.lo...@gmail.com>:
Hi,
i have setted my system resources for a given user via login.conf, but
after the user login the ulimit -a returns different values.
Here is my login.conf entry:
general:\
:coredumpsize=infinity:\
:cputime=infinity:\
:datasize=infinity:\
:filesize=infinity:\
:stacksize=infinity:\
:maxproc=infinity:\
:memorylocked=infinity:\
:memoryuse=infinity:\
:openfiles=infinity:\
:vmemoryuse=infinity:\
:auth=krb5-or-pwd:\
:ignorenologin:\
:localcipher=blowfish,6:\
:ypcipher=old:\
:priority=-5:\
:ftp-chroot:\
:tc=default:
But when i log in, what i get for ulimit is:
sioux@gustav$ ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 8388608
stack(kbytes) 32768
lockedmem(kbytes) unlimited
memory(kbytes) unlimited
nofiles(descriptors) 7030
processes 1310
My doubt is why data and stack limits are not infinity ?
Thanks in advance.
I think this could be because the developers do not want datasize or
stack to be unlimited :)
I do recall reading somewhere in the lists that the maximum amount of
virtual memory that can be allocated by a process using malloc is 8GB
and is set by MAXDSIZ (in vmparam.h). Hopefully I am not giving you a
totally silly answer and someone more knowledgeable will answer your
question correctly.
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca
---------------------------------------------
This message was sent using ForeTell-POST 4.9
There's a physical limit to memory available on a machine: RAM + swap space.
It is impossible to grant a program more memory than that.
Using swap space incurs a very large performance decrease.
It is advantageous to all users of a system for programs to request
as little memory as is reasonable.
For various reasons, an arbitrary upper limit is set even if more
RAM and swap space is available. The OS architects set that limit
based on their best judgement of the tradeoff between program size
and overall system utility. Avoiding paging of code and stack avoids
truly painful bad performance.
Also, the kernel is mapped into the address space of all user programs.
On 32-bit machines, this limits the maximum possible user program address
space to about 2G. On 64-bit machines the constraint depends on how many
bits of address space are actually implemented and other considerations.
Limiting stack space to 32M is fairly reasonable - recursion to huge depth
may be theoretically wonderful but rarely useful in real life, and
allocating multi-megabyte stack variables is likely a programming error.
One might argue for a somewhat larger maximum for truly twisty programs,
but I haven't seen many programs that need over 8M. When main memory
becomes 10X larger and CPU speeds 10X higher changing the limit might
be considered.
The above is from observing various OSes externals and internals.
The kernel group obviously know far more about how the limits are chosen.
Geoff Steckel
