Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jun 1999 18:17:47 -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.990628181714.10602B-100000@current1.whistle.com>
In-Reply-To: <199906282038.NAA24584@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 
> 					<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?Pine.BSF.3.95.990628181714.10602B-100000>