FreeBSD Foundation and iXsystems Collaborate to Further the Cause of High Performance Computing on FreeBSD
dillon at apollo.backplane.com
Sun Feb 9 14:25:56 PST 2014
The cpu limit is only because we are using atomic ops to manipulate
the cpumask (thus 64 bits max), and integrate the pmap LOCK bit into
the cpumask (leaving us with 63 bits).
This is not all that difficult to fix, but it's probably 40-80 man-hours
of work to:
(1) Adjust all the places that reference the mask directly to use macros
(2) Move the pmap lock bit somewhere else (and possibly rework how pmap
locking operates in that situation). The pmap lock bit is used to
prevent smp invalidations from missing a cpu that has just switched
a related thread in.
(3) The IPIQ fifo arrays might need some adjustment but would probably
work without modification.
(4) Route table handling might need some adjustment but would probably
work without modification (updates might be a bit inefficient).
I can't think of any other work that would be needed beyond that. The
kernel already does a very good job minimizing IPI traffic so expansion
to 256 cpus should not add any new inefficiencies.
It would make a good GSOC project.
More information about the Kernel