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 ?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds