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 [EMAIL PROTECTED]
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-smp
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
