Date: Wed, 13 Jan 1999 00:39:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bad@wireless.net (Bernie Doehner) Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: limiting per process swap space utilization like Solaris ulimit? Message-ID: <199901130039.RAA15783@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.95.990112155324.21181A-100000@wireless.net> from "Bernie Doehner" at Jan 12, 99 03:54:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Why is it that under bash's ulimit -v, the swap space utilization is the > > sum of the data segment size and the stack size? > > Sorry, I should have said, I understand the reason for this (you cannot > swap out more than entire size of the program). The question should rather > have been, WHY/HOW can the value for swap space limitation not be reduced > to less than data segment + stack? OK. Basically, any page that can be dirtied will potentially have to take up swap space for it to be swapped out if it's dirty. So the minimum size of swap space necessary is data segment size plus stack size (data segment size including any allocated heap space via sbrk(2)). Consider the alternatives if you could limit swap size to less than this: If the kernel needs to make the pages non-resident to make room for other pages, it has to: (A) Kill the program, since it's not allowed to swap those pages. (B) Keep the pages in memory instead of swapping them, reducing teh available physical memory for all other programs (open itself to denial of service attack by some schmuck setting the limit to zero and then sbrk'ing as much memory as possible until physical memory is exhausted). Not a good thing. It *might* be useful to limit swap space to larger than the current usage, but only in the case that that limit is not applied, as above, but to an agregate of the data space size and the stack size. The advantage of this would be one more frob for users to tweak. The disadvantage is that it's more work to enforce this when allocating backing pages in the trap handler, making page allocation slower, with the only benefit from the tradeoff being another frob. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901130039.RAA15783>