Subject: Re: auto-spl simple locks
To: Jason Thorpe <firstname.lastname@example.org>
From: Bill Sommerfeld <email@example.com>
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).
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.