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

On Tue, Jun 07, 2005 at 05:46:33PM -0700, Jason Thorpe wrote:
>=20
> On Jun 7, 2005, at 3:55 PM, YAMAMOTO Takashi wrote:
>=20
> >while i completely agree that the only sane way is "highest IPL =20
> >first",
> >lock-per-IPL implies that no interrupt handlers take kernel_lock, i =20
> >guess.
> >i think it can work if we don't care about performace.
>=20
> I don't want lock-per-IPL.
>=20
> What I want is "make the subsystems that run in those IPLs truly SMP-=20
> safe".  That way we get actual performance.

In the long run, I think everyone wants that. My understanding of this=20
thread is it is all about how do we get there from here. Do we do it in a=
=20
sequence of direct jumps, or do we take an intermediate, mid-term step=20
that we will eventually get rid of.

One other issue is that of resources. How many people do we have that can=
=20
take different subsections from where they are now to full SMP-safe? I can=
=20
thiunk of two, but I'm not sure who else could take an arbitrary=20
subsystem and make it SMP-safe. Do we wait for the two of you to start=20
fixing components, or do we take a step in a direction we know we don't=20
want to stay in order to let other folks work on parts of the problem.

If we de-couple fixing all "higher" IPLs from fixing the networking code,=
=20
Jonathan can start working on fixing the networking stack. Someone else=20
could start on either the disk or the vm systems in too. Even if not, we=20
still have two developers working on SMP-safe interrupt handling rather=20
than one now....

Take care,

Bill

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

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

iD8DBQFCppiXWz+3JHUci9cRAp01AJ9ttp+sF8LD9Y+R+aBRVQ8IdLCc5QCgmPAQ
b7dcjyu1l/KV2S0MwMmXq5U=
=gpRu
-----END PGP SIGNATURE-----

--7AUc2qLy4jB3hD7Z--