Date: Thu, 3 Jun 1999 20:06:11 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Brian Somers <brian@Awfulhak.org>, dyson@iquest.net, Amancio Hasty <ahasty@mindspring.com>, "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 Message-ID: <Pine.BSF.4.05.9906032005270.80993-100000@semuta.feral.com> In-Reply-To: <199906040303.UAA02303@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9906032005270.80993-100000>