--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 06, 2005 at 06:23:51PM -0700, Jonathan Stone wrote:
> In message <20050607004001.GB1761@netbsd.org>,
> Bill Studenmund writes:
>=20
> >I guess my confusion is that don't we have interrupt handlers grab the b=
ig
> >lock now? So don't we have an implicit mono-leveling now?
>=20
> Yes. however, I recall considerable distaste for merely exchanging the
> big-lock choke point for a choke-point whereby MD code flattens all
> device interrupts to a single IPL level. (Though purely selfishly,
> that _would_ let me run multiple instances of SMP-safe drivers
> concurrently with a single CPU at splsoftnet().)

I don't think my point was clear. I was trying to point out that being=20
able to support SMP-safe drivers is independent of what the SMP-unsafe=20
drivers are doing (grabbing big_lock, grabbing a flat interrupt lock, or=20
grabbing per-IPL locks).

So if you want to write SMP-safe drivers, why do you need per-IPL locks?=20
Don't you just need the SMP-safe interface? I think I know the answer but=
=20
I want to hear you say it. :-)

> >Or is that it's important to have the big lock and one or more separate
> >interrupt locks?
>=20
> I think it's even more simple than that.  After the last couple of
> emails, I beleive Yamamoto-san and I are in complete agreement about
> where we want to end up. Yamamoto is correct, the IPL-locking is
> clearly an interim solution.  I think Yamamoto-san and I really
> disagree only over how long that "interim" is likely to be.

I was speaking only in terms of the interim.

> I fear the "rework entire IPL" will take long enough that the
> IPL-locking SPL*()s will be around for quite some time -- more than
> long enough to be well worth its keep. (OTOH, I'd be very glad
> to be wrong).
>=20
> I don't mean to point fingers at any other group, but if you look at
> other open-source projects, and how long they've have taken to get
> from a stable "big lock" kernel to a stable biglock-free kernel, with
> "all at once" approaches, then an incremental, piecmeal-testable,
> piecmeal-deployable approach starts to look like a pretty reasonable
> idea.

I too think that a number of incrimental changes (or evolutions) is what=20
we need. It's really hard to get a big change right the first time, as=20
there will be things you only learn about from doing, and you won't be=20
doing until you have code.

> Besides, I'm impatient, I want to start working on SMP-safe network
> drivers, oh, last month.

And I'd love you to. I'd also love an SMP system to be servicing disk and=
=20
network interrupts at the same time.

Take care,

Bill

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

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

iD8DBQFCpUB1Wz+3JHUci9cRAmlwAJkBeI11X4mJ5v0zXgB0uGVuRKrVQQCdEhKa
LOiSzHMBZsqbHSL2mAWCMAk=
=obKX
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--