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

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
>     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.

I think we should analyze this from a syscall point of view -- which syscalls are touching which subsystems which are still under the MP lock?  Having a table like this would help in deciding which subsystems are the most important targets.  Then we could rank these targets relative to benefit and level of complexity.

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

cheers
  simon

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00005.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20080428/9ccc1225/attachment-0020.obj>