:> 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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
