Date: Mon, 28 Jun 1999 08:59:38 -0700 From: Kirk McKusick <mckusick@flamingo.McKusick.COM> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Peter Wemm <peter@netplex.com.au>, Julian Elischer <julian@whistle.com>, 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: <199906281559.IAA02733@flamingo.McKusick.COM> In-Reply-To: Your message of "Mon, 28 Jun 1999 10:35:21 PDT." <199906281735.KAA23042@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Mon, 28 Jun 1999 10:35:21 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: Kirk McKusick <mckusick@flamingo.McKusick.COM>, Julian Elischer <julian@whistle.com>, 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 ) References: <19990628165738.E590283@overcee.netplex.com.au> :Certain places use B_CALL and have biodone() from the b_iodone routine, :so we can't reliably use B_ASYNC as an indicator of needing to reassign :to LK_KERNPROC. We have to do it on a case-by-case basis. : :It's easier to do cluster_head processing at the point it's gathered :rather than in BUF_KERNPROC(). : :vfs_cluster.c is confusing, but I think I've figured out how to get it :right. I'm not 100% sure about checking for B_CALL in both cases prior :to VOP_STRATEGY(), and maybe reqbp needs to be considered for the first :... There has got to be a better way to do this. This is unbelievably messy. Please, guys. I am all for stabilizing what was committed but I just spent a month removing fragility from the buffer cache code, and this is adding it right back in. This stuff is just too fragile. Even if we fix it now, it is only going to cause serious problems in the future. It looks to me that these hacks exist to get around potential problems with exclusive lock recursion. We are not *doing* any exclusive lock recursion right now. I am fairly confident that Kirk can implement the new softupdates-related elements without having to resort to exclusive lock recursion, with only a little thought on the matter. Can we please get rid of the lock reassign junk that only exists to support exclusive lock recusion and instead go with something simpler? That way we can remove all of these BUF_KERNPROC calls which have been strewn all over the code. We have the luxury of time here, can we please do this implementation right instead of rushing through making design mistakes? -Matt 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 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?199906281559.IAA02733>