> :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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
