From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Mon, 14 Jul 2008 16:08:19 -0400 From: a@9srv.net In-Reply-To: <1216052962.22701.26.camel@goose.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Plan 9 and multicores/parallelism/concurrency? Topicbox-Message-UUID: e6a32e16-ead3-11e9-9d60-3106f5b1d025 // But do you know of any part [of Plan 9] that would be // beneficial for highly-SMP systems? Beneficial compared to what, I guess. I agree with your comment that most of the pressure is on the application rather than the kernel. The kernel's biggest contribution here is keeping processes inexpensive compared to unix. As for the system overall, there's something to be said for decomposing problems to interfaces that can be represented in the namespace; then, to a large extent, it doesn't matter whether we're talking about one box or many. // On the other hand, may be the trick is not to scale a single // kernel on something like that but have multiple kernels // running under something like Xen or kvm. There's certainly something to be said for this in many cases, but it hardly takes away any burden from application developers. They've just got more practice doing it for logically distinct machines. It lets kernel developers off the hook, but I'm not sure that's a good thing. // It'll be interesting to see how a single Plan9 kernel scales on // something like a Batoka box (256 hardware threads per box, // 64 physical cores). Send me one and I'll see if I can find out. =E2=98=BA Anthony