The scheduler doesn't scale too well...
> I was actually pretty happy with how easy (relatively) the networking
> was to thread nicely.
>
> The point is, you have to make a captivating argument for ccClusters,
> what does it buy us now that we've done a lot of the work you are
> telling us it will save?
The most captivating arguments are along the following lines:
- scales perfectly across NUMA fabrics: there are a number of
upcoming architechures (hammer, power4, others) where the
latency costs on remote memory are significantly higher. By
making the entire kernel local, we'll see optimal performance
for local operations, with good performance for the remote
actions (the ccClusterFS should be very low overhead).
- opens up a number of possibilities in terms of serviceability:
if a chunk of the system is taken offline, only the one kernel
group has to go away. Useful in containing failures.
- lower overhead for SMP systems. We can use UP kernels local
to each CPU. Should make kernel compiles faster. ;-)
At the very least it is well worth investigating. Bootstrapping the
ccCluster work shouldn't take more than a week or so, which will let
us attach some hard numbers to the kind of impact it has on purely
cpu local tasks.
-ben
-- Fish. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/