Date: Thu, 15 Apr 1999 14:38:37 -0400 (EDT) From: Mikhail Teterin <mi@misha.cisco.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: current@freebsd.org Subject: Re: swap on Irix (overcommiting, etc.) Message-ID: <199904151838.OAA98565@misha.cisco.com> In-Reply-To: <199904151808.LAA47676@apollo.backplane.com> from Matthew Dillon at "Apr 15, 1999 11:08:52 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904151838.OAA98565>