> On Mon, Jun 25, 2007 at 11:30:16AM -0700, Bill Stouder-Studenmund wrote:
>> On Mon, Jun 25, 2007 at 08:06:37PM +0200, Joerg Sonnenberger wrote:
>> > Is it really a good idea to make the vnode locking even more
>> > complicated?

It will make it simpler. As I said there's a lot of confusion between
what's covered by the long term lock that Unix has had ~forever (B_BUSY),
and the short term lock (b_interlock) which is fairly recent. I suspect
that softdep has contributed to that: it's the only substantial chunk of
file system code that's run from an interrupt handler.

Ignoring softdep, the places I can see where we really need a mutex are
also those where we're playing with vnodes. For example: adjusting the
per-vnode clean/dirty buffer lists, adjusting vnode reference counts,
adjusting v_numoutput and waking waiters. That's why I want to merge
the locks, so that instead of locking two objects already glued together
we take one lock to cover both.

>> Are you sure this will make vnode locking more complicated?
>
> Well. We add a dependency of a subsystem that was currently not caring
> about vnodes to the vnode locking.

I don't agree. How the disk buffers work is intimately tied to how vnodes
work. It's not a distinct subsystem.

Andrew