Date: Mon, 28 Jun 1999 23:53:40 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: Kirk McKusick <mckusick@flamingo.McKusick.COM>, Peter Wemm <peter@netplex.com.au>, Alan Cox <alc@cs.rice.edu>, Mike Smith <mike@smith.net.au>, "John S. Dyson" <toor@dyson.iquest.net>, dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey <grog@lemis.com> Subject: Re: Found the startup panic - ccd ( patch included ) Message-ID: <199906290653.XAA26968@apollo.backplane.com> References: <Pine.BSF.3.95.990628230641.10602D-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:The problem I see with this is teh resource load in times of critical
:resource shortage. If you need to suddenly generate a writable page..
:where does the page come from? If resources are not available, I guess you
:could just stall the write until the original page is reconstituted (after
:soft updates remerges backed out data), but there is the danger that the
:write request could be very large, and that duplicated data could be both
:very expensive and very "surprising" to the system.
:
:Still it's an intriguing concept. How much CPU do you "use" to generate
:the writable copies before you start going backwards in performance.
:
:julian
This was the first thing I considered. It turns out to be a non-problem
because you've already initiated the I/O - if you have a critical resource
shortage the blockage occurs in a process context and not an interrupt
context, and the you are guarenteed a page will become available 'soon'.
Duplicating the data is almost certainly not going to be as expensive
as waiting for the I/O to complete would be. And it really doesn't happen
all that often since the buffer cache normally operates in an LRU fashion.
Where it wins the most is that it allows the filesystem to do write-behind
without intefering with performance.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906290653.XAA26968>