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 <[email protected]> > 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 >
