From owner-freebsd-hackers Tue Feb 16 18:36:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id A821D11345 for ; Tue, 16 Feb 1999 18:35:24 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA02570; Tue, 16 Feb 1999 19:35:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd002474; Tue Feb 16 19:35:07 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA17123; Tue, 16 Feb 1999 19:34:51 -0700 (MST) From: Terry Lambert Message-Id: <199902170234.TAA17123@usr08.primenet.com> Subject: Re: inode / exec_map interlock ? (follow up) To: bright@cygnus.rush.net (perlsta) Date: Wed, 17 Feb 1999 02:34:51 +0000 (GMT) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "perlsta" at Feb 16, 99 02:20:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What's the deal here? Matt, even though your swapper lists pages as > 'free' does it actually keep them around for reuse? What happens when a > page is READ faulted in, is the backing swap kept allocated to save on IO > later? I don't think the swapper does this, though it would be an optimization to utilize swap for clean pages from backing store. One real problem here is the ihash cache, which should probably not exist, but has to because the vnodes for UFS are not managed by UFS. You basically lose the association with the vnode, even if the inode stays in cache. One thing I was worried about after a casual perusal of the code (I don't have a hell of a lot of perusing time, at the moment, casual or otherwise) was dirty pages after a fork that are marked copy-on-write in the circumstance that the fork is *not* followed by an exec. I thought there might be a boundary condition that the new code was overlooking (but perhaps I'm missing something; it *was* a casual perusal). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message