mmm, object code bloat.

I suspect that most of the bloat comes from the conditional
(alp->lock_level != LK_SPL_NONE) test; I suspect that most of it will
go away if you add a separate "spllock" type, and include the
(constant at each call site) SPL code as a parameter to the lock
macro.   (LOCKDEBUG can check it against the value in the lock).

	spl_lock(&uvm.fpageqlock, LK_SPL_IMP);

	spl_unlock(&uvm.fpageqlock);

Given that you have to visit each of the call sites to remove the
separate splfoo()/splx() calls, it doesn't seem like such a problem..

[i wrote the above, and then read: ]

    Unfortunately, in most cases in the kernel, of a given object type, some
    instances will need to be interrupt-protected, and many won't.  So, in
    those cases, you need to perform the "do I need to lock?" check.

hmm.  this seems surprising to me; I would think that most call sites
will always take locks of a particular "type" and thus the correct
LK_SPL value would be constant at a call site.

    Anyhow, I'm interested in what people think about this, or if people
    have any other ideas.  I'll state now that auto-spl locks are the
    only sane way I can fix a locking protocol error that exists in the
    i386 pmap, even in the non-MULTIPROCESSOR case.

can you go into more specifics about this?  Maybe there's another
way which won't end up bloating all the simple_lock/simple_unlock call
sites which don't need it.

						- Bill