Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Mon, 14 Jul 2008 13:33:01 PDT "Roman V. Shaposhnik" <rvs@sun.com>  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.