Re: cvs commit: src/sys/conf files src/sys/ddb db_ps.c src/sys/i386/i386 trap.c src/sys/kern init_main.c kern_synch.c kern_usched.c lwkt_thread.c usched_bsd4.c usched_dummy.c src/sys/sys globaldata.h thread.h usched.h

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi,
:
:It is quite possible that I misunderstand something here, so I
:apologise if this is a stupid question, but:
:
:I thought one of the goals of DragonFlyBSD (one which from what I have
:read is very novel, and seems to make much logical sense) is that
:threads are not moved between CPUs, and that this is *UNLIKE* FreeBSD
:5+ series which do allow threads to move between CPUs. That is the
:main use of LWKT and provides the ability for lockless algorithms to
:be used.
:
:Therefore, I guess what I do not understand is how giving a process a
:CPU mask that would allow it (e.g. on a quad core machine) to run on
:say two processors would then translate into the DFly model - does it
:mean that if the process has two LWPs, their associated kernel threads

    The kernel thread scheduler (LWKT) does not load balance threads 
    across cpus.  So e.g. kernel threads do not migrate.  Threads also
    do not get preemptively migrated while running in kernel mode.  However,
    the BSD4 scheduler, which is responsible for managing threads that
    run in user mode, WILL migrate threads.

    The BSD4 scheduler tries to be smart about it, but it does do it.
    You pretty much have to because user processes do not represent a
    controlled load.  The kernel has no idea how little or how much cpu
    a user process will need.  So, e.g. if you are running two long-running
    computationally intensive progress the BSD4 scheduler clearly needs
    to make sure that they run on different cpus.

    Basically the way it works is that a user process is always woken up
    on the same cpu it went to sleep on UNLESS there is some other
    user process already running on that cpu and that other user process
    has a higher priority. 

    If the original cpu is not available, the BSD4 scheduler tries to migrate
    it to some other idle cpu, or it tries to find a cpu running a lower
    priority thread and asks that cpu to reschedule to pick up the thread.

    When a cpu is ready to switch to another user process the BSD4 scheduler
    pulls the highest priority user process off the run queue.  It currently
    checks the two highest priority processes for cpu affinity and chooses
    the one that matches if possible, otherwise it just pulls the highest
    process it can find off the run queue and schedules it on the cpu (which
    at this point might not be the same cpu the process was originally
    running on).

:would be split between the CPUs under their respective LWKT
:shcedulers? Or am I somehow confusing kernel space and user space? How
:would a single process with a single associated LWP and thus kernel
:thread (which I believe have a  1:1 relationship) benefit from a CPU
:mask specifying two or more CPUs to process on?
:
:Sorry for taking up your time if what I said seems silly.
:
:Thanks for your patience, Alex J Burke.

    There will always be certain classes of jobs where fine control of
    the cpu scheduling might be desireable.  The best example of this
    that I can think of is a video game where you might want the graphics
    to be driven off of one cpu and the game mechanics to be driven off
    another.

    Another example might be in a heavy proxy system (well, once we finish
    locking up the network stack).  You might want to run network device
    interrupts on one cpu and the IP stack on another.  Or in a router you
    might want to lock network interfaces to particular cpus.

    Or, say, if you are running a workstation and running a TV tuner or
    video thingamabob you might want to dedicate one cpu entirely to X
    (or whatever).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>