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

[Yonghong Yan]

Hi Matt,

How are you and thanks for the info. If nobody violent ever, I can certainly try to work on the fix, or mentor some student for it (need some time to get on track for this). 

Come back to my original question: if we donot have contact for this system, can we initiate the communication with FreeBSD community to access the system for experiment?

Thanks
Yonghong

> On Feb 9, 2014, at 4:25 PM, Matthew Dillon <dillon at apollo.backplane.com> wrote:
> 
>    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
>