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

[Matthew Dillon]

:Wow, that's ugly :)
:
:Maybe we can extend this to a master mask to enable CPU hotswapping.  The=
: wicked thing is that we can test the most code necessary already on vker=
:nels!  (Not that we would ever run on such big iron which supports this)
:
:cheers
:  simon

    Yah, its an ugly simple hack which is easily replaceable when we need
    something more sophisticated.

    Cpu hot swapping is definitely possible.  The user scheduler is per-cpu
    so per-cpu control of user process scheduling is really easy to do.
    All the other per-cpu kernel threads can easily be turned off except
    for the network protocol threads.  Even the route table thread can be
    turned off.

    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.

   -1  ??  BL     0:00.00  (rtable_cpu 3)
   -1  ??  BL     0:00.00  (tcp_thread 3)	<<< network proto thread
   -1  ??  BL     0:00.02  (udp_thread 3)	<<< network proto thread
   -1  ??  BL     0:00.00  (netisr_cpu 3)	<<< network proto thread
   -1  ??  BL     0:00.00  (taskqueue 3)
   -1  ??  BL     0:00.00  (dsched 3)
   -1  ??  BLM    0:00.00  (usched 3)
   -1  ??  BL     0:00.00  (softclock 3)
   -1  ??  BLM    1:16.33  (idle_3)

    --

    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!

    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.

						-Matt