Re: scheduler rewrite

[Antonio Vargas <windenntw@xxxxxxxxx>]

On Tue, 7 Dec 2004 11:54:45 -0800 (PST), Matthew Dillon
<dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> :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

Hmm... I will assume you are just doing 1:1 scheduling, so how is the
userland scheduler deciding who runs, by sending SIGSTOP and SIGCONT
to other threads???

>     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>
> 


-- 
Greetz, Antonio Vargas aka winden of network

http://wind.codepixel.com/

Las cosas no son lo que parecen, excepto cuando parecen lo que si son.