DragonFly kernel List (threaded) for 2008-04
Re: Summer of Code: Extending Multi-Processing (MP) support
:Alright! Time to get going :)
:First order of business: questionnaire
:As you might have guessed, my main motivation with working on
:parallelizing parts of the kernel is an academic / recreational one as
:opposed to an "applied interest" one. Given that, I probably have a
:naive view on what would be most "useful" to begin and focus on...
:Therefore, what I would like to know, is what specific subsystems anyone
:would like to see prioritized, and why?
The network stack is the best-defined area because everything is threaded,
but if you are looking for a more personal area to work on I would say
the LWP vs PROC APIs are the place to go.
Last year we got a light weight process (LWP) threading abstraction.
Essentially one has a struct proc 'process' abstraction, but each thread
running under that process has its own 'struct lwp' abstraction.
MP access to LWPs are localized and do not need to be locked, but MP
access to the underlying struct proc is not MP safe. In addition, many
of the kernel APIs used in that part of the code are not yet MP safe.
Making struct proc access MP safe (by adding appropriate spin locks or
lockmgr locks or lwkt_token locks) would allow us to push the MP lock
further into the code. It would be a big deal.
Another area that really needs MP help, but is a *LOT* more difficult,
is the VFS API (the VOP interface). I do not think it would be a good
project because it will take a huge amount of work to get those APIs