Subject: Re: Concern about IPL levels and spinlocking
To: matthew green <>
From: Bill Studenmund <>
List: tech-kern
Date: 12/18/2005 18:06:45
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 18, 2005 at 10:59:28PM +1100, matthew green wrote:
>   =20
>    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=
>    levels.
> 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=
for long.

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.

Take care,


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

Version: GnuPG v1.2.3 (NetBSD)