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

[Matthew Dillon]

:Hi Matt,
:
: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() ?
:
:-- 
:Sergey Glushchenko

    You mean why is it a SYSINIT instead of a call through the
    registration subsystem?  

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>