--JYK4vJDZwFMowpUq
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=
md64
>    & i386, splipi > splhigh. On alpha and vax, though, splhigh < splipi. =
That
                                                                 >
>    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 =
is=20
>    an MD definition (macppc and sparc don't seem to have it), MI code wou=
ld=20
>    not directly see the problem. In fact, on vax, splipi < most other spl=
=20
>    levels.
>=20
> 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=
=20
hidden. Maybe it won't normally be an issue as we shouldn't be at splhigh=
=20
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=
ove=20
>    to a fine-grained spin locking on all MP architectures if MI code does=
n't=20
>    have one hierarchy to code to.
>=20
> 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.
>=20
> perhaps i'm missing something?

Take it a bit further. :-) The real problem with different levels comes in=
=20
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,

Bill

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

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

iD8DBQFDphW1Wz+3JHUci9cRAoBeAJ9J9GCD5I5ipwG8tfNWuNidrN6BUwCeN4yN
28PpFr8geKjhf7ImwUW9o4M=
=sZXF
-----END PGP SIGNATURE-----

--JYK4vJDZwFMowpUq--