On Wed, Mar 03, 2004 at 04:12:35PM -0500, Darrin B. Jewell wrote:
> I'm looking at ways around these problems.  Some possiblities
> include:
>   1. always take splbio before taking v_interlock.
>      - impractical and huge imapct on other code
>   2. split v_interlock into two separate interlocks, one to
>      protect stuff used inside biodone and one for everything
>      else.
>   3. Move some or most of the work done by biodone into a separate
>      helper thread context, similar to aiodoned, which can safely take
>      the v_interlock.
> 
> Right now, i'm favoring possibility #3, but I'm still examining the
> problem.  I'm also considering putting v_dirtyblkhd and v_cleanblkhd
> under the protection of the v_interlock and adding a new interlock
> to protect syncer_workitem_pending/v_synclist.

aiodoned is not something I'm especially happy with, I just did it that way
for expediency.  I don't think we want to keep aiodoned or your proposed
#3 biodoned in the longer term.  if a fix is really important in the
short term, it's probably ok (since aiodoned doesn't seem to cause any
problems really).

I'm hoping that eventually we get some better MP locking primitives that don't
require the calling code to know about the particular IPL prerequisites for
each lock acquisition.  then we would need to convert all the MP locking to
use the new primitives once, but ideally after that we could change the MP
locking implementation without changing all the callers again.
I don't know if that's the discussion you wanted to have right now though.

-Chuck