From owner-freebsd-current Mon Jun 28 21:20:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8EC95151B7 for ; Mon, 28 Jun 1999 21:20:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA26149; Mon, 28 Jun 1999 21:20:21 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 21:20:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199906290420.VAA26149@apollo.backplane.com> To: Julian Elischer Cc: Kirk McKusick , Peter Wemm , Alan Cox , Mike Smith , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey Subject: Re: Found the startup panic - ccd ( patch included ) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message