On Mon, 14 Jul 2008 13:33:01 PDT "Roman V. Shaposhnik" <[EMAIL PROTECTED]> 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.
