To view parent comment, click here.
To read all comments associated with this story, please click here.
Per-CPU scheduler and CPU affine processes which migrate
between CPUs are nothing new. Nor would it particularly
be of help for a cluster because migrating processes
between CPUs with a per-cpu scheduler is by no means
equivalent to migrating processes between nodes in a
cluster.
Now if the cluster is SSI on a page level (like Linux's
virtual iron capability AFAIK), then you may not have to
explicitly migrate processes but they could migrate
naturally according to the scheduler. This also seems
like a pretty bad idea unless the scheduler is very
specialised, because you could have a process with local
memory scattered all over your cluster.
"and because of the way the system is developed it has a potential to perform and scale really well in a clustered environment"
Well yes, we are talking about software cache coherency
schemes for SSI clusters. So what exactly is it about
the way this system is developed that gives it this
potential?
"talk on ZFS which Matt Dillon thinks will work very well in such an environment and you may end with something that works VERY well."
I recall him saying ZFS is a clustered filesystem or can be used over a cluster. This is not the case.




Member since:
Well that is the the reason (cache locality) that Light Weight Kernel Threads were developed. The processes themselves are per CPU and are migrated (and communicate via a light weight messaging protocol.) This suits itself to clustering because you have an increased L2 utilization and a means of migrating processes to systems with heavy loads to other non-taxed systems in a cluster. Cache coherency systems are not new, however they are new to this system and because of the way the system is developed it has a potential to perform and scale really well in a clustered environment, talk on ZFS which Matt Dillon thinks will work very well in such an environment and you may end with something that works VERY well.