Date: Fri, 7 Jan 2000 11:01:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brett Glass <brett@lariat.org> Cc: hackers@freebsd.org Subject: Re: Possible optimization in VM? Message-ID: <200001071901.LAA88409@apollo.backplane.com> References: <4.2.2.20000106220706.00b67650@localhost> <4.2.2.20000107004708.01c12740@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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?200001071901.LAA88409>