From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 14 Jul 2008 13:33:01 PDT." <1216067581.14715.45.camel@goose.sun.com> From: Bakul Shah Date: Tue, 15 Jul 2008 01:01:52 -0700 Message-Id: <20080715080153.1B5B25B50@mail.bitblocks.com> Subject: Re: [9fans] Plan 9 and multicores/parallelism/concurrency? Topicbox-Message-UUID: e6f6dd72-ead3-11e9-9d60-3106f5b1d025 On Mon, 14 Jul 2008 13:33:01 PDT "Roman V. Shaposhnik" wrote: > Solaris's scheduler is not shy when it comes to big iron (100+ CPU SMP > boxes) but even it had to be heavily tuned when a Batoka box first > came to the labs. When you have physcical threads (CPUs), virtual > threads and a non trivial memory hierarchy -- the decision of what > is the best place (hardware-wise) for a give thread to run becomes > a non-trivial one. Kernels that can track affinity properly rule > the day. I suspect a lot of this complexity will end up being dropped when you don't have to worry about efficiently using the last N% of cpu cycles. When your bottleneck is memory bandwidth using core 100% is not going to happen in general. And I am not sure thread placement belongs in the kernel. Why not let an application manage its allocation of h/w thread x cycle resources? I am not even sure a full kernel belongs on every core. Unlike you I think the kernel should do even less as more and more cores are added. It should basically stay out of the way. Less government, more privatization :-) So may be the plan9 kernel would a better starting point than a Unix kernel.