From owner-freebsd-hackers Tue Jan 12 16:40:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA15293 for freebsd-hackers-outgoing; Tue, 12 Jan 1999 16:40:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15223 for ; Tue, 12 Jan 1999 16:40:04 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA16181; Tue, 12 Jan 1999 17:39:19 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd016057; Tue Jan 12 17:39:15 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA15783; Tue, 12 Jan 1999 17:39:03 -0700 (MST) From: Terry Lambert Message-Id: <199901130039.RAA15783@usr08.primenet.com> Subject: Re: limiting per process swap space utilization like Solaris ulimit? To: bad@wireless.net (Bernie Doehner) Date: Wed, 13 Jan 1999 00:39:03 +0000 (GMT) Cc: dillon@apollo.backplane.com, hackers@FreeBSD.ORG In-Reply-To: from "Bernie Doehner" at Jan 12, 99 03:54:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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