Re: ulimit -d/-m do not actually work

[mlelstv%serpens.de@localhost (Michael van Elst)]

gdt%lexort.com@localhost (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.