threadlock patch

Julian Elischer julian at elischer.org
Thu May 10 21:29:50 UTC 2007


Marko, 
We are just reorganising our effort on this stuff 
to put it in a bit more of an organised manner.

for a start.. there is a perforce branch that covers this work..

 http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=/depot/user/attilio/attilio%5fschedlock&HIDEDEL=NO

(hopefully that didn't wrap)
also we are using the mailing list smp at freebsd.org
to discuss this. I suggest that you and any of the guys there who are intersted in
pushing this sign up to catch the fun. I've CC'd this to the list..
I suggest we use that list to communicate so that there is a record.
also makes is easier for others to follow and join when needed.

Julian


Jeff Roberson wrote:
> I just returned home from a long trip so I don't have time to review 
> your turnstile and rwlock changes in detail.  I do have a few comments 
> about the patch that may be helpful as well as some questions.
> 
> The threadlock patch is really just a first starting point to get us to 
> per-cpu run queue locks.  By itself it will only minorly reduce 
> contention for sched lock since in most cases the per-cpu thread lock 
> still points to this single scheduler lock.  There is another bit of 
> work that must be done in ULE to permit the use of per-cpu locks.  I do 
> not believe it is practical to do this on 4BSD.  Once this is done we 
> should see some impressive performance improvements on larger machines, 
> especially with context-switch heavy workloads.
> 
> I would like to ask what your environment is.  How many cpus do you have 
> per machine and what kind of workload are they running?  What problems 
> are you running into that lead you to this patch?  I do not know in what 
> capacity nokia uses FreeBSD.  I'm very interested in finishing up this 
> work and having a good test case and industry involvement would help 
> that along.
> 
> Thanks,
> Jeff





More information about the freebsd-smp mailing list