Subject: Re: splx() optimization [was Re: SMP re-eetrancy in "bottom half" drivers]
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/06/2005 15:10:17
--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 06, 2005 at 12:05:13PM -0700, Jonathan Stone wrote:
> >On Mon, Jun 06, 2005 at 03:45:52PM +0900, YAMAMOTO Takashi wrote:
> >
> >If we have the resources to do that, it probably is quicker.
> >
> >However I think the big questions are 1) if we do this transition to
> >per-level locks, how much harder will it be to transition to full
> >locking afterwards? i.e. once we have the per-IPL locking Jonathan
> >suggested, will we be behind where we are now? I think not, but it's good
> >to know. 2) Do we have folks who want to do the transition to per-IPL
> >locking more than work on individual fixup? i.e. do we have developer
> >resources that are more available for the fixup than the per-IPL work?
>=20
> Per-IPL locking lets developers work on drivers piecemeal.  In
> principle, nindividual developers can tackle individual drivers.
> Driver SMP-safe changes might even be tested on real hardware before
> they are committed.
>=20
> "Whole-IPL-at-a-time" has a much higher, um, Least Publishable Unit,
> if you'll forgive me.  Given that we're a volunteer organization, then
> I'd expect per-IPL locking to make significantly sbetter use of
> available developer cycles.

I'm now confused a bit.

If we have the ability to mark drivers as SMP-safe on a per-driver case,=20
does it matter if we have one-big-lock or per-spl locks? Isn't it the same=
=20
work either way (in terms just of letting a driver be SMP-safe or not)?

I thought the biggest win of per-SPL locks was that we could immediately=20
move to having multiple CPUs in an SMP system being in interrupt routines=
=20
at the same time.

> >As above, I think doing the per-IPL fixup will not make it harder to go =
to
> >true fine-grained locking later. It effectively may be a distraction, but
> >I don't think it's harder to turn a section from a big lock to
> >fine-grained than it is to turn it from a per-IPL lock to fine-grained. =
Am
> >I missing something?
>=20
> The lock-per-IPL enables us make individual drivers SMP-safe, mark
> them as such. locore/MD code can and will call SMP-safe drivers with*out*
> acquiring the per-IPL lock.  So I think lock-per-IPL makes it *easier*
> to move remove locking for the IPL-at-a-time approach: we will already
> have some (maybe all?) drivers for that IPL which are SMP-safe.

As above, how is that different from not having to aquire the big lock?

Take care,

Bill

--ReaqsoxgOBHFXBhH
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCpMnJWz+3JHUci9cRAnl3AJ0VaDZ8ewfkgLjjww7bZNttql9QXgCcDmnE
hRjLLpIbh1LGQ6elqA7b97k=
=xPHU
-----END PGP SIGNATURE-----

--ReaqsoxgOBHFXBhH--