Date: Thu, 15 Apr 1999 14:44:46 -0400 (EDT) From: Chuck Robey <chuckr@picnic.mat.net> To: mi@aldan.algebra.com Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG Subject: Re: swap on Irix (overcommiting, etc.) Message-ID: <Pine.BSF.4.10.9904151440470.18456-100000@picnic.mat.net> In-Reply-To: <199904151838.OAA98565@misha.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9904151440470.18456-100000>