FreeBSD Foundation and iXsystems Collaborate to Further the Cause of High Performance Computing on FreeBSD

[Matthew Dillon]

    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
	instead

    (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.

							-Matt