From owner-freebsd-hackers Thu Jun 3 20:12: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id BAA4A15A52 for ; Thu, 3 Jun 1999 20:12:02 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id UAA15646; Thu, 3 Jun 1999 20:08:37 -0700 Date: Thu, 3 Jun 1999 20:06:11 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: Brian Somers , dyson@iquest.net, Amancio Hasty , "David E. Cross" , freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 In-Reply-To: <199906040303.UAA02303@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Now I'm getting a bit torqued at this. Yes, there are problems here, > :but rather than keeping it to yourself what the problems are, how about > :being constructive in suggesting ways we can all improve things. > > A number of conversations and threads have already taken place on the > topic, though most have been with small private pools of people. John, DG, > and I ( and maybe a couple of other people ) have discussed rerouting > VFS operations through the VM system. I think that leaked onto the public > lists at one point. Poul has a number of really good ideas that he's > talked to me about that I find very exciting... basically ways to fix the > buffer cache operation and VFS layering by splitting it into a struct buf > and a layerable struct ioreq. Poul's ideas are the most realizeable > that I've heard to date. Eventually I think we will have to do both. > > We also need to fix vnode locking for VFS ops. Right now there is a > single vnode/inode lock that is being used both to lock exclusive > operations and to lock I/O operations. What we really need is to > have a master lock for atomicy and range-locks for I/O. > > For example, right now operations on a large file ( say, a 'history' > file for a news system ) make relatively inefficient use of the VM > cache. This is because the vnode is being locked exclusively through > I/O operations, causing other I/O operations that could be accessing > cached data to block unnecessarily. The other big problem is with > locking order. Some operations lock the vnode and related VM map > in a different order then other operations, leading to a potential > deadlock situation ( also occurs in known mmap/write lockups ). > > Sometimes its hard to keep track of all the things that need fixing. > There are a lot of dependancies. Some things need to be fixed before > work can begin on other things. Thank you. That's the clarification I needed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message