User: Password:
|
|
Subscribe / Log in / New account

changing ulimit -v behaviour

changing ulimit -v behaviour

Posted Feb 17, 2011 10:02 UTC (Thu) by pjm (subscriber, #2080)
Parent article: Go's memory management, ulimit -v, and RSS control

If a user requests RLIMIT_AS (ulimit -v) instead of RLIMIT_RSS (ulimit -m) then it may well be that the user actually wanted it to limit (say) swap usage as well as just the resident set size.

Yes, it may well also be because RLIMIT_RSS is "hard to implement", as the article notes, and indeed consequently unimplemented on many systems including current versions of Linux; but that doesn't seem like a good basis on which to suggest that RLIMIT_AS should be implemented as RLIMIT_RSS.

The problem with RLIMIT_DATA (ulimit -d) is that it only affects brk (and its wrapper sbrk), not mmap, and so doesn't limit memory allocated with mmap; and many memory allocators use mmap instead of brk.

Rather than change RLIMIT_AS (or even just ulimit -v as distinct from RLIMIT_AS) to limit only resident set size, would it be better to either change it only so as to exclude PROT_NONE mappings; and/or change RLIMIT_DATA behaviour such that it also limits malloc-like memory mappings (say those that are either private or anonymous), so that people could reasonably switch from ulimit -v to ulimit -d ?


(Log in to post comments)

changing ulimit -v behaviour

Posted Feb 18, 2011 1:19 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Indeed, I use RLIMIT_AS extensively and I think I am like most users in that I'm not interested in limiting real memory usage. That just doesn't concern me. What concerns me is a runaway process using up all the real memory plus swap space and causing an innocent process to fail.

Of course, I don't get that either, because of all the virtual address space that is not backed by memory and swap space. The first time this bit me was with my X server, whose mmap of the frame buffer on the video controller failed for "lack of resources."

I would welcome an RLIMIT that just covers anonymous memory. I don't think RLIMIT_AS could be changed for that, because some people today use it the way I did with my X server: add the size of the frame buffer to the limit I really wanted.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds