From owner-freebsd-current Thu Apr 15 11:41:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 4F6F315275 for ; Thu, 15 Apr 1999 11:41:33 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.2/8.9.1) id OAA98565; Thu, 15 Apr 1999 14:38:37 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199904151838.OAA98565@misha.cisco.com> Subject: Re: swap on Irix (overcommiting, etc.) In-Reply-To: <199904151808.LAA47676@apollo.backplane.com> from Matthew Dillon at "Apr 15, 1999 11:08:52 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 15 Apr 1999 14:38:37 -0400 (EDT) Cc: current@freebsd.org Reply-To: mi@aldan.algebra.com X-Mailer: ELM [version 2.4ME+ PL52 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon once wrote: > :On Irix, each swap area has the following parameter (from swap(1M)): > : > : vswap The size the system believes the area can hold. This is > : always greater than or equal to pswap and maxswap. > : > :This way, an administrator can control the amount of overcommited > :memory (making it 0 if neccessary). It may be sufficient to have this > :as a centralized parameter, rather then a per swap area. > 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... > FreeBSD does it right - it only allocates swap when it needs to > swap something out of main memory. The total available VM is > essentially the amount of main memory plus the amount of swap > (non-inclusive of mmap()'d files which do not take any swap at > all). FreeBSD is perfect for my existing needs... > :They also have priorities of the swap areas (only swap here when > :areas with higher priorities are full), and an ability to stop > :paging onto a particular area. Mmmm... What about this two? -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message