cvs commit: src/sys/kern kern_fork.c kern_usched.c src/sys/sys usched.h

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
    So the only real issue are the network protocol threads, because they
    manage data structures used by random processes in the system.  We
    would need to change the network mux from a mask to a lookup table.
Oh, I see easy ways to deal with this while maintaining a mask:  Do some bit modification (rotate left, or so) and try again.  Fall back to CPU0.  Or simply use the next higher CPU.  All these are deterministic operations and could be used to relocate the PCBs before turning off a CPU.

    I've noticed some other issues with 31-cpu mode, primarily
    the fact that we don't really need 31 TCP protocol threads and we
    certainly do not need to replicate the route table 31 times.  I gotta
    say though, the fact that those things actually WORK properly even
    when replicated so many times is a great validation of the
    implementation!
Well, if somebody has 31 CPUs, why shouldn't he want to use all of them to distribute the load?  Unless there is a packet queued, there won't be any scheduling overhead anyways.

    I'm not going to worry about it at the moment.  The number of
    network protocol threads are easy to restrict, the mux is just a mask
    (1, 2, 4, 8) and could be made a modulo.  The route table is more of an
    issue since the routing infrastructure currently assumes each cpu has
    its own, but it should be possible to use a mux on that too or at
    least restrict it to the cpu's the network protocol threads are on.
I think the nicest way for the routing table would be RCU.  That's basically the classical thing:  Many reads, few writes.  All reads are wait-free, writes need a lock and freeing is done lazily lateron when it is guaranteed that no thread could ever still reference a piece of data.

cheers
 simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00006.pgp
Type: application/octet-stream
Size: 252 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/commits/attachments/20070702/7176f415/attachment-0022.obj>