From owner-freebsd-current Thu Apr 15 11:49:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 96A2015275 for ; Thu, 15 Apr 1999 11:49:29 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id OAA61243; Thu, 15 Apr 1999 14:44:46 -0400 (EDT) Date: Thu, 15 Apr 1999 14:44:46 -0400 (EDT) From: Chuck Robey To: mi@aldan.algebra.com Cc: Matthew Dillon , current@FreeBSD.ORG Subject: Re: swap on Irix (overcommiting, etc.) In-Reply-To: <199904151838.OAA98565@misha.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Apr 1999, Mikhail Teterin wrote: > > I think they finally got rid of vswap in later IRIX's after they > > fixed the core swapping code to 'overcommit'. The reality behind > > the virtual swap concept w/ IRIX is based on issues with the original > [...] > > Mmm, that's how they use(d) it then... But can we have a way for an > admin to control the amount of overcommited memory? Ranging from 0 -- no > overcommitment to the entire addressable space less the phisical storage > (the current situation)... And this is different from the per-user class > limit. > > I guess, I'd settle for being able to specify the per-user class: > > . datasize limit in percents of the total available RAM+swap > . kill-order, so the kernel will start killing with the least > important users (and services running in their own sandboxes) > > Does not fix the non-compliance with ANSI, strictly speaking... This is the part that gets me. You keep claiming ANSI C non-compliance, and we are compliant. If you want to claim non-compliance, then get out the spec and quote chapter and verse. There is nothing in the spec that says how the underlying OS has to treat processes on a global scale. This hasn't a darn thing to do with ANSI C compliance. If you want to argue that you don't like memory overcommit, that's valid, but claiming the non-compliance is throwing FUD. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message