From owner-freebsd-current@FreeBSD.ORG Sun Apr 20 08:31:12 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E2A037B401 for ; Sun, 20 Apr 2003 08:31:12 -0700 (PDT) Received: from noisebox.cypherpunks.to (adsl-208-201-229-163.sonic.net [208.201.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05AC043FBD for ; Sun, 20 Apr 2003 08:31:11 -0700 (PDT) (envelope-from shamrock@cypherpunks.to) Received: from VAIO650 (adsl-208-201-229-160.sonic.net [208.201.229.160]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noisebox.cypherpunks.to (Postfix) with ESMTP id 0D99F110 for ; Sun, 20 Apr 2003 08:31:09 -0700 (PDT) From: "Lucky Green" To: Date: Sun, 20 Apr 2003 08:30:57 -0700 Message-ID: <003201c30751$dccffef0$6601a8c0@VAIO650> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030420101401.GA2821@HAL9000.homeunix.com> Subject: RE: Broken memory management on system with no swap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2003 15:31:12 -0000 David wrote quoting Bruce: > > So the bug is mainly in vm making only a relatively useless > statistic > > available. On my systems, `Inact' is usually mainly for > (non-dirty) > > VMIO pages. > > Right. dillon was planning to separate out the dirty and > clean pages in the inactive queue at some point. ISTR that > his intent was along the lines of optimizing write clustering > by making dirty pages easier to find, or something along > those lines. But the number of inactive dirty pages is > useful as a statistic by itself, too. So how do I find out what is consuming those "inactive" pages? And how do I determine if those pages can be discarded or not? > > The system has little difficulty discarding these, so > > I haven't had problems with processes being killed despite > not using > > (much | any) swap since memories became cheap enough a few > years ago. > > I generally configure swap and use it only once in a blue > moon. Since there's no truly graceful way to handle an > out-of-swap condition, I'm usually glad that it's there once > in a while. But Lucky's concern is that confidential data > should never hit the disk. Exactly. Which is why I just replaced my old 128MB RAM/256MB swap server with a new 1GB RAM server. I still fail to understand why a setup that never was anywhere near running out of memory in the previous configuration would run out of memory with more RAM than it had RAM and swap combined. If I can't do in 1GB what I could do in 128 + 256 MB, then somewhere there is a bug. How do I find out where? It is correct that I don't want confidential data to hit the disk. I could use GBDE to encrypt the swap partition, but being one of the more active beta testers of GBDE, I am not convinced that GBDE is sufficiently well-tested at this time that I would want to rely on it for swap. Nor should I have to use GBDE to encrypt swap. That's why I bought a server with a GB of RAM. What am I missing? BTW, I since ran additional tests. Even with no GBDE device attached, the inactive memory eventually accounts for most of the memory shown by top: Mem: 30M Active, 788M Inact, 148M Wired, 34M Cache, 112M Buf, 1660K Free Swap: 2048M Total, 2048M Free (I did enable swap until somebody tells me how to determine what is causing the problem). Thanks, --Lucky