Subject: Re: auto-spl simple locks
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
List: tech-kern
Date: 07/30/1999 07:41:38
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