From owner-freebsd-hackers Fri Jan 7 11: 1:55 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 987F714F65 for ; Fri, 7 Jan 2000 11:01:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA88409; Fri, 7 Jan 2000 11:01:42 -0800 (PST) (envelope-from dillon) Date: Fri, 7 Jan 2000 11:01:42 -0800 (PST) From: Matthew Dillon Message-Id: <200001071901.LAA88409@apollo.backplane.com> To: Brett Glass Cc: hackers@freebsd.org Subject: Re: Possible optimization in VM? References: <4.2.2.20000106220706.00b67650@localhost> <4.2.2.20000107004708.01c12740@localhost> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. The copy operation is already as lazy as it can get, with or without C2. C2 itself is just a struct vm_object -- very cheap for the kernel to create. :> 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? Yes, you would. They would all be concentrated in C1. :> 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? No, just having 'more' doesn't help. They must be the correct pages -- the ones most likely to be touched if the sublayer forks again -- for the optimization to work. I don't think the number of pages, fewer or greater, really matters. :> 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 You haven't really collapsed C2 into B because you still can't collapse C1 and B together. All you've really done is simply avoided creating C2 and possibly helped with the dead-page case a bit, but you unbalanced the VM Layering in the process. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message