Re: scheduler rewrite

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Matt, if I recall correctly, on Amiga we had a shareware program which
:manipulated he usually static priorities for each task according to
:fairness rules, it was called executive... are you advocating
:mantaining the same split-up, kernel with fixed prios and then
:userland scheduler adjusting these "fixed" prios?
:
:ps. goto http://de.aminet.net/aminetbin/find?executive and then executive.lha
:
:-- 
:Greetz, Antonio Vargas aka winden of network
:
:http://wind.codepixel.com/

    Not quite.  The way the scheduling works in DragonFly is that the LWKT
    thread schedule uses (for all intents and purposes) permanent fixed
    priorities.

#define TDPRI_IDLE_THREAD       0       /* the idle thread */
#define TDPRI_USER_IDLE         4       /* user scheduler idle */
#define TDPRI_USER_NORM         6       /* user scheduler normal */
#define TDPRI_USER_REAL         8       /* user scheduler real time */
#define TDPRI_KERN_LPSCHED      9       /* scheduler helper for userland sch */
#define TDPRI_KERN_USER         10      /* kernel / block in syscall */
#define TDPRI_KERN_DAEMON       12      /* kernel daemon (pageout, etc) */
#define TDPRI_SOFT_NORM         14      /* kernel / normal */
#define TDPRI_SOFT_TIMER        16      /* kernel / timer */
#define TDPRI_EXITING           19      /* exiting thread */
#define TDPRI_INT_SUPPORT       20      /* kernel / high priority support */
#define TDPRI_INT_LOW           27      /* low priority interrupt */
#define TDPRI_INT_MED           28      /* medium priority interrupt */
#define TDPRI_INT_HIGH          29      /* high priority interrupt */
#define TDPRI_MAX               31

    The userland scheduler is responsible ONLY for scheduling threads that
    are running in userland.  The userland scheduler schedules only one such
    thread at a time, and always at e.g. TDPRI_USER_NORM.  It does not 
    schedule multiple threads (running in userland) with LWKT at the same 
    time.  When a userland thread enters the kernel it's priority is bumped
    up to TDPRI_KERN_USER for the duration of its existance in kernel space,
    and when it returns to userland it goes back to TDPRI_USER_NORM (or it
    gets descheduled if the userland scheduler decides another userland 
    process is more important).  The actual priority bumping is a
    delayed-action effect that only occurs if the thread blocks in the kernel,
    so it doesn't slow down the syscall path at all.

    For SMP the userland scheduler is replicated... that is, each cpu will 
    have at most one thread running in userland scheduled with LWKT at any
    given moment.  In this case the per-cpu userland schedulers and scheduler
    helper kernel threads talk to each other to schedule from a common pool 
    of runnable userland processes.

    The biggest advantage of this methodology is that we can in fact implement
    multiple userland schedulers and switch between them on the fly because
    the userland schedule is only a relatively simple layer operating on top
    of LWKT.  So it is theoretically easy to switch the userland portion of
    the scheduler on a live system.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>