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

[Matthew Dillon]

: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 operatio=
:ns and could be used to relocate the PCBs before turning off a CPU.

    Oh hell, I'm being an idiot.  We don't have to do any of that.  All
    we have to do is migrate the protocol thread ITSELF to a different
    cpu.  So we simply move the protocol thread for cpu #5 over to cpu #1
    (so there are two protocol threads on cpu #1) until cpu #5 comes back
    up.  Hahaha.  OMG, that is so simple.

:
:Well, if somebody has 31 CPUs, why shouldn't he want to use all of them t=
:o distribute the load?  Unless there is a packet queued, there won't be a=
:ny scheduling overhead anyways.

    Presumably if one really had 31 cpus he would also have sufficient
    memory and not the measily 64M-1G that we specify when we run the
    vkernel.  Plus I don't think a 31-cpu machine would be used to route a
    full BGP table.  When Jeff and I discussed this last year we figured 
    that it was a moot issue.

    We might have to adjust the route table caches a bit, one issue that
    did come up (which you saw my solution for in the OBJCACHE commit)
    is that when you replicate things massively the memory use can exceed
    the defaults set up for the kmalloc infrastructure.

:I think the nicest way for the routing table would be RCU.  That's basica=
:lly the classical thing:  Many reads, few writes.  All reads are wait-fre=
:e, writes need a lock and freeing is done lazily lateron when it is guara=
:nteed that no thread could ever still reference a piece of data.
:
:cheers
:  simon

    I really hate RCU.  I mean, with a passion I hate it.  I think it is
    too non-deterministic, meaning that it can lead to coding errors and
    hard-to-find bugs.  A far prefer cpu-localization models which I think
    anyone experienced with the DragonFly codebase would agree are far more
    understandable and less prone to bugs.  Perhaps not higher-performing,
    but certainly not lower-performing.

						-Matt