DragonFly kernel List (threaded) for 2006-05
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
: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
: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
: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 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