Matthew Dillon wrote:
quoted text
>     Making struct proc access MP safe (by adding appropriate spin locks=
 or
quoted text
>     lockmgr locks or lwkt_token locks) would allow us to push the MP lo=
ck
quoted text
>     further into the code.  It would be a big deal.
>=20
>     Another area that really needs MP help, but is a *LOT* more difficu=
lt,
quoted text
>     is the VFS API (the VOP interface).  I do not think it would be a g=
ood
quoted text
>     project because it will take a huge amount of work to get those API=
s
quoted text
>     MP safe.

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