From owner-freebsd-current Mon Jun 28 18:18:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2CDF114EF8 for ; Mon, 28 Jun 1999 18:18:30 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id SAA51513; Mon, 28 Jun 1999 18:17:48 -0700 (PDT) Date: Mon, 28 Jun 1999 18:17:47 -0700 (PDT) From: Julian Elischer To: Matthew Dillon 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 ) In-Reply-To: <199906282038.NAA24584@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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. > :The port of my buffer locking code from BSD/OS has caused problems > :largely because of a different buffer cache implementation and > :especially SMP models between the two systems (BSD/OS has no spl's > :for example). However, this is not a half baked idea that I have > :come up with and thrown in without thinking. Recursive locking is > :*required* to get stacking filesystems like union and loopback > :working reliably. As they currently stand they are full of code to > :try and track locks at layers all up and down the stack. This code > :is really nasty and in many cases broken (leading to deadlocks or > :crashes). The snapshot code also is most easily implemented with > :recursive locking, the alternative being to put lock monitoring > :all through bmap and block allocation code. So yes, it would be > :wonderful if the world could be simple, and I am not a huge fan of > :the complexity of the buffer locking code. But, I have considered > :the alternatives and they are worse. > : > : Kirk > > Wow! Timeout! Miscommunication. > > I am talking strictly about struct buf locking. I understand and agree > completely that recursive locking is absolutely necessary for the > VFS layering! > > I am not throwing your work out - precisely the opposite, I want to keep > your work pretty much as is except for two things: (1) I want to replace > lockmgr locks ( and I don't mind implementing recursive exclusive locking > in the replacement, though I would rather avoid it! ), and (2) I want to > find a better way to implement the BUF_KERNPROC() stuff... basically I > want to try to find a way to localize the necessary effect in one place > in the code rather then have the BUF_KERNPROC() macros strewn all over the > code. Same effect, slightly different code organization, that's all. > > There must be a choke point somewhere where we can put the code. > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message