Date: Thu, 3 Jun 1999 20:03:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.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: <199906040303.UAA02303@apollo.backplane.com> References: <Pine.BSF.4.05.9906031930510.80993-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
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?199906040303.UAA02303>