Date: Mon, 28 Jun 1999 23:12:06 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.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: <Pine.BSF.3.95.990628230641.10602D-100000@current1.whistle.com> In-Reply-To: <199906290420.VAA26149@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Jun 1999, Matthew Dillon wrote: > > :ok > : > : hadn't seen this one when I sent the previous email.. > : > :Julian > : > : > :On Mon, 28 Jun 1999, Matthew Dillon wrote: > : > :> :You are right that the buffer cache is very tricky. It is hard to > :> :change it in ways that preserves functionality and performance. > :... > > I've had a long phone conversation with Kirk. We're basically on the > same page. The concentration has got to be to stabilize what we have > first, and we will worry about formalizing (and cleaning up) the lock > semantics later. > > Basically what it comes down to is that the exclusive locks on struct > buf's are going to have to move to an always-recursive model to handle > certain situations that come up both with softupdates and with VFS > layering. The original B_BUSY locks were exclusive but non-recursive. > The differences between recursive and non-recursive exclusive locks > plus unexpected side effects from lockmgr() operation are what led to > the bugs in the original commit. For example, recursive exclusive locks > require ownership reassignment while non-recursive exclusive locks do > not. This led to the KERNPROC hack, and is why it needs to stay in > at least until we can formalize the lock semantics and find a choke point > (maybe involving fiddling with b_flags) to implement the case more > appropriately. > > I think I also have a good line on how to finally fix the > blocking-during-write-I/O problem. Basically it involves taking > a page out of UVM and making VMIO pages copy-on-write for the purposes > of an I/O, allowing the write operation to take out a shared lock on > the buffer instead of an exclusive lock. The I/O operation gets the > real page, and if the system needs to write to it while the I/O is in > progress the system allocates and copies the page on the fly and the > page being used for the I/O is detached (and freed at the end of the I/O). > We would essentially get rid of the bogus page junk and replace it with > copy-on-write junk. > > Kirk and I both think that we can get rid of nearly all the blocking > conditions that occur during an access to a buffer that is simultanious > with an I/O being performed on the same buffer. > 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. (unless I completely misunderstood what you said.) julian > -Matt > > 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?Pine.BSF.3.95.990628230641.10602D-100000>