g...@lexort.com (Greg Troxel) writes:
>I suspect that "ulimit -d" does not work correctly, so I wrote a test
>program, which simply allocates 4K chunks and writes an int into each.
>It keeps a count, and prints the amount it was able to allocate in kB.
> data seg size (kbytes, -d) 8388608
> max memory size (kbytes, -m) 32220468
malloc doesn't use the "data segment", so that limit doesn't apply to it.
-d the data segment size of a process (kilobytes)
RLIMIT_DATA The maximum size (in bytes) of the data segment for a
process; this defines how far a program may extend its
break with the sbrk(2) system call.
You can try sbrk(2), it should still obey the data segment size (and
may fail if you use it concurrently with malloc()).
"max memory size" is about physical memory usage and isn't a hard limit.
-m the total physical memory that can be in use by a
process (kilobytes)
RLIMIT_RSS The maximum size (in bytes) to which a process's resident
set size may grow. This imposes a limit on the amount of
physical memory to be given to a process; if memory is
tight, the system will prefer to take memory from
processes that are exceeding their declared resident set
size.
Things were much easier when these limits were invented, in particular
without multithreading and shared libraries, a single heap (the
"data segment") was sufficient for all memory allocations.
