From owner-freebsd-hackers Thu Jun 3 20: 3:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7327115A50 for ; Thu, 3 Jun 1999 20:03:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA02303; Thu, 3 Jun 1999 20:03:41 -0700 (PDT) (envelope-from dillon) Date: Thu, 3 Jun 1999 20:03:41 -0700 (PDT) From: Matthew Dillon Message-Id: <199906040303.UAA02303@apollo.backplane.com> To: Matthew Jacob 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 References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I sure do not intend those hacks to remain in there forever! The I/O :> subsystem is a holy mess. The only reason I'm not working on it right now :> is because I think Poul is intending to work on it later in the year. :> : :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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message