From owner-freebsd-hackers Sat Jan 1 14:35: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 40AC414DCA; Sat, 1 Jan 2000 14:35:03 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA93859; Sat, 1 Jan 2000 14:35:02 -0800 (PST) (envelope-from dillon) Date: Sat, 1 Jan 2000 14:35:02 -0800 (PST) From: Matthew Dillon Message-Id: <200001012235.OAA93859@apollo.backplane.com> To: Kirk McKusick , Greg Lehey , Mike Smith , Tom , freebsd-hackers@FreeBSD.ORG Subject: Re: Slight mistake in my DaemonNews column Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ach, I also forgot the all-shadowed optimization, which is actually fairly important. Well, if anyone brings it up here's the problem and solution: "But doesn't the object model cause an ever deeper stack of layers as a server forks children out?". Even though we do not optimize the dead-page case we *do* optimize the all-shadowed case. Lets say that the parent, C1, touches all the pages in B causing a copy-on-write to occur to C1. C1 now entirely shadows B and therefore can BYPASS B. +----+----+ +----+ | C1 | C2 | | C2 | +----+----+ +---------+ | B | -> | C1 | B | +---------+ +---------+ | A | | A | +---------+ +---------+ Once the bypass occurs, B has only one reference and C2 and B can be collapsed together. Ok, so you might ask the question "But wait, what if B is large object (represents the entire data area of the program)? Doesn't that mean that neither C1 or C2 are likely to ever completely shadow B?". Answer: This is often true at the second level (B), but usually not true at the third level (C1 or C2). If C1 (the parent) or C2 (the child) forks again, then it is likely that something in the new layer D? will be able to completely overshadow C1 or C2 and thus D? will be able to bypass C1 or C2. The end result is that in typical useage, even with a lot of working going on, the object stack does not run more then 4 deep. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message