From owner-freebsd-hackers Fri Jan 7 0: 0:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B7D8715655 for ; Fri, 7 Jan 2000 00:00:31 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id BAA23881; Fri, 7 Jan 2000 01:00:25 -0700 (MST) Message-Id: <4.2.2.20000107004708.01c12740@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 07 Jan 2000 01:00:26 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Possible optimization in VM? Cc: hackers@freebsd.org In-Reply-To: <200001070542.VAA79015@apollo.backplane.com> References: <4.2.2.20000106220706.00b67650@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:42 PM 1/6/2000 , Matthew Dillon wrote: > Hmm. Well, you could copy the page to C1 in order to avoid creating > a C2 layer, at least as long as you do not have other entities sharing > B directly (e.g. C3, C4, ...). Yes, if you had C3, C4, etc. (multiple children), you'd need to make sure that each of them could get at what was originally in B. This means more copying -- either to each of the C's or someplace else. The thing is, most forks are followed by execs. The most common case is that they would never look at the old contents of B. So, it pays to make the copy operation as "lazy" as possible, since the odds are that not a single child will look at B. > This sort of optimization would reduce > the parent object's layering complexity but at the cost of increasing > the child object's layering complexity. > > The problem that we hit is that we really mess up the 'All Shadowed' > optimization if we start throwing pages into C1 that C1 didn't touch > itself. The C1 layer may wind up contaiing a significant number of > *additional* dirty pages, pages the child never actually touched > itself and thus pages that an additional forked child of the child > probably will not ever touch. They'd be substitutes for pages that would have been in C2, so we'd have as many dirty pages in either case, right? > This will prevent the 'All Shadowed' > optimization from occuring, resulting in a potentially deep VM Object > layering on one side of the graph. Hmmm. It seems to me that it would cause more pages to be "shadowed," thus actually accelerating the application of the optimization. Am I off base here? > The key to the 'All Shadowed' optimization is that it depends on locality > of reference in nearby layers. The locality of reference is messed up > if we start copying pages to layers whos governing processes didn't > actually touch. > > Another reason why we wouldn't want to do this is that it complicates > the VM Object layer accounting. It would be hard to tell whether C1 could > be collapsed into B without a C2. Or, if not hard, definitely more complex > then the C1,C2 -> B case where the collapsability of layers is visually > obvious. Well, in essence, we've really collapsed C2 into B (since it's serving to hold the parent's pages). So, haven't we already "won" by going straight to the state that an optimization might have achieved? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message