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

[Alex Burke]

:While I am here, can the schedulers allow userspace to specify a cpumask
:a thread is willing to run on, some highend software e.g database
:systems may want this feature, as they are intend to manager their
:CPU locality like they did for RAW device.
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
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.