From owner-freebsd-current Fri Apr 16 1:15:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from titan.metropolitan.at (mail.metropolitan.at [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id 49ACA151FF for ; Fri, 16 Apr 1999 01:15:29 -0700 (PDT) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id <26KYC5WD>; Fri, 16 Apr 1999 10:15:42 +0200 Message-ID: <55586E7391ACD211B9730000C11002761795EC@r-lmh-wi-100.corpnet.at> From: Ladavac Marino To: 'Matthew Dillon' , Mikhail Teterin Cc: current@FreeBSD.ORG Subject: RE: swap on Irix (overcommiting, etc.) Date: Fri, 16 Apr 1999 10:11:47 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Matthew Dillon [SMTP:dillon@apollo.backplane.com] > Sent: Thursday, April 15, 1999 9:38 PM > To: Mikhail Teterin > Cc: current@FreeBSD.ORG > Subject: Re: swap on Irix (overcommiting, etc.) > > If some of you are wondering why some of us are saying this > guarenteeing > of memory is a crap argument, it's because it *IS* a crap > argument. > [ML] hey, I know it's a crap argument, that's why I did not raise any objections concerning memory overcommit (even though I am the one who has read the STDC document in an anal-retentive manner regarding malloc failures). One simply has to allocate sufficient swap so that the processes do not get killed before the machine swaps itself to death :) In my experience, this is about 5xRAM for a smallish desktop, 1xRAM for a database server (but do not let any badly behaved programs run on the latter machine). There is a "feature" of HPUX (and I think SINIX and Solaris as well) that they are capable of potentially swapping into a mounted filesystem. The actual filesystem swapping is very slow, and is used by the system as the last resort only--merely, swap is "reserved" there (reserved in the sense that the systems idea of free space in the filesystem is reduced by (a fraction of) the reserved amount i.e. the system keeps statistics about how much VM would have been needed if no overcommit were used, how much of the swap was really used, and how much of the filesystem swap was actually used). If the sysadmin ever sees non-zero actual filesystem swap usage, he better increases RAM/swap. Alas, I do not quite know whether this "feature" were possible in FreeBSD, or how hard would it be to implement it. It does not really solve anything, but it brings you somewhat further along. OTOH, just normal swap monitoring on FreeBSD provides you with the same information, and is practically as safe (okay, the filesystem swappers have an emergency swap area as well, which means that they can err on the low side with actual swap, but this doesn't really bring anything.) /Marino (who really did not expect this thread will explode so :) > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message