Subject: Re: Concern about IPL levels and spinlocking
To: matthew green <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 12/18/2005 18:06:45
Content-Type: text/plain; charset=us-ascii
On Sun, Dec 18, 2005 at 10:59:28PM +1100, matthew green wrote:
> But I found some spl levels swap relative ordering. For instance, on a=
> & i386, splipi > splhigh. On alpha and vax, though, splhigh < splipi. =
> worries me, as if we ever write MI code that ends up depending on being
> able to pass IPIs around, it'll fail on alpha & vax. And since splipl =
> an MD definition (macppc and sparc don't seem to have it), MI code wou=
> not directly see the problem. In fact, on vax, splipi < most other spl=
> splipi() is MD, thus it doesn't matter what it's definition is. i am
> not sure we will ever have MI splipi() required functionality.... this
> seems like a non-problem.
I agree we won't see an splipi(). In some ways that makes things a bit=20
worse, as IPIs are only invoked by calls into MI code and all this will be=
hidden. Maybe it won't normally be an issue as we shouldn't be at splhigh=
One upshot I see is that it'll mean we may not be able to get all=20
processors into ddb; as I understand it ddb tells all other CPUs to=20
stop/halt via an IPI. If another CPU is stuck in an slphigh() loop, we=20
can't stop it.
I agree that is a rare event. But when it happens, it'll be a pain. :-)
> I'm really not sure what to do about this, but it'll be real hard to m=
> to a fine-grained spin locking on all MP architectures if MI code does=
> have one hierarchy to code to.
> since all levels/drivers need to be fixed, fixing one platforms highest
> level first is not detrimental to other platforms. i'm not sure that this
> is a real problem? eg, if sparc/sparc64 have to lag because of splaudio
> vs. splsched, they will just have to keep the current biglock.
> perhaps i'm missing something?
Take it a bit further. :-) The real problem with different levels comes in=
when we have systems that need to go from having one such lock to having=20
two. Grabbing them in the correct lock order becomes tricky. Doable, of=20
course. But we will end up with platform-dependent hierarcy differences.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----