Re: Summer of Code: Extending Multi-Processing (MP) support

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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?
:
:-- 
:Robert Luciani

    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
    MP safe.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>