DragonFly commits List (threaded) for 2005-11
Re: cvs commit: src/sys/conf files src/sys/i386/i386 machdep.c src/sys/kern init_sysent.c kern_usched.c syscalls.c syscalls.master usched_bsd4.c src/sys/sys syscall-args syscall-hide.h syscall.h syscall.mk sysproto.h sysunion.h usched.h
:I agree with all changes to my original code, except one: why should we
:call rqinit() explicitly if there is a common scheduler interface and
:registration routine usched_register() ?
You mean why is it a SYSINIT instead of a call through the
I agree with you, it certainly can be. However, those are static
variables in the usched module so from a practical standpoint there
isn't going to be much of a difference between initializing them
via SYSINIT verses via the registration interface.
To really do this correctly we need to take all those static's and
embed them in a larger structure that also includes usched_bsd4, and
use this structure as a kind of softc for the scheduler. In that
situation the initialization would of course have to run through the
registration interface. It would also give us the ability to implement
independant copies of the scheduler. So e.g. with the cpumask feature
we could install one userland scheduler on cpu's 0 and 1, and a
completely independant scheduler on cpu's 2 and 3 that happens to be
the same type scheduler.
In anycase, I see this as an area that needs more development, but
I think that you can leave the BSD4 scheduler somewhat alone other then
for ABI fixes in order to focus your time on your lottery scheduler.
It's up to you, though. I certainly don't mind you formalizing the
infrastructure and cleaning BSD4 at the same time if that is what you
want to do!
Also note that to really make the userland scheduler work well this
way we need to make it MP safe (not require the Big Giant Lock).
This is something we need to do anyway since the scheduler interactions
are in the critical system call path. It is just a matter of doing it
cleanly and not mixing such changes with other unrelated work.