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>

I think we should analyze this from a syscall point of view -- which sysc=
alls are touching which subsystems which are still under the MP lock?  Ha=
ving a table like this would help in deciding which subsystems are the mo=
st important targets.  Then we could rank these targets relative to benef=
it and level of complexity.

I'd like to find a subsystem where we can observe the impact of paralleli=
zing it -- also maybe a subsystem which warrants using a more sophisticat=
ed approach, maybe by splitting data on CPUs, etc.  What I want to avoid =
is creating a fine grained locking infrastructure for all structures in t=
he kernel -- we can and should do better than that.  Of course some subsy=
stems are not in the fast path or can't be split onto multiple CPUs;  the=
n we don't have a choice.

cheers
  simon