Date: Wed, 17 Feb 1999 02:34:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@cygnus.rush.net (perlsta) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <199902170234.TAA17123@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.96.990216140929.10060w-100000@cygnus.rush.net> from "perlsta" at Feb 16, 99 02:20:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902170234.TAA17123>