Re: scheduler rewrite
On Tue, 7 Dec 2004 11:54:45 -0800 (PST), Matthew Dillon
<dillon@apollo.backplane.com> 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@backplane.com>
>
--
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.
討論串 (同標題文章)
完整討論串 (本文為第 7 之 10 篇)：