On 10/02/2010 02:41 PM, Alan Cox wrote:
To be honest your bigger problem is finding enough application
parallelism and enough parallel user space apps. That and memory or I/O
bandwidth on servers.
The kernel will run on supercomputers with over 1000 processors. Not all
workloads are handled well at that scale so if you threw 1000 random user
instances on it you wouldn't get great results in a lot of cases.
On a desktop its instructive to measure how many processor cores ever end
up running at once. About the only time an 8 core box seems to use all
cores at once is compiling kernels.
On a server you've got more chance as you've often got a lot of work
hitting the box from multiple sources, but in many cases then the
bottleneck ends up being I/O and memory bandwidth unless you've got a
board with separate RAM hanging off all the CPUs, and you spent real
money on the I/O subsystem.
This is actually one of the things that really hurt certain workloads.
There are some that simply don't parallelise and the move to many cores
and to clusters has left them stuck.
Alan
Yes I agree.
Most (if not all) of open source apps are not implemented with
hundreds or thousands of parallel threads.
But many commercial applications are heavily multithreaded
and it is here that the optimum locking granularity will have
a substantial value.
I am wondering if we will ultimately end up splitting up massively
parallel architectures into specialized sets where each set will
be responsible for some major operating system task (i.e. operations)
in order to reduce lock contentions and head off race conditions
that can easily crop up when an optimum locking scheme is pursued.
Perhaps some things from the past will be the future.
Remember the IO channel? :) :)