In response to a question raised on the dragonfly-kernel mailing-list, Matt Dillon [interview] gives an overview of plans to revise the DragonFly userland scheduler, the second of two schedulers that Dragonfly currently utilizes in a layered fashion. Matt explains:"There are actually two schedulers.. there's the LWKT scheduler, which is as close to perfect as its possible to be, and there is the userland scheduler, which is the one that needs work.".
Matt goes on to describe the benefits of the intended re-design:" 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."
In addition to on-fly switching of schedulers, there are also plans to allow multiple schedulers to run in parallel. Full thread with relevant links follows.
From: Glenn Johnson [email blocked] To: dragonfly-kernel Subject: scheduler rewrite Date: 2004-12-02 18:27:09 I recall that Matt said a scheduler rewrite was needed for DragonFly. I was just curious what the time frame on that is. The scheduler performance is a weak spot for DragonFly at the moment although I do not know if it is any better in FBSD-5. Thanks. -- Glenn Johnson
From: Matthew Dillon [email blocked] Subject: scheduler rewrite Date: 2004-12-02 19:50:23 :I recall that Matt said a scheduler rewrite was needed for DragonFly. I :was just curious what the time frame on that is. The scheduler :performance is a weak spot for DragonFly at the moment although I do not :know if it is any better in FBSD-5. : :Thanks. : :-- :Glenn Johnson The scheduler should be in fairly good shape now, though there are still a few weak spots here and there. There are actually two schedulers.. there's the LWKT scheduler, which is as close to perfect as its possible to be, and there is the userland scheduler, which is the one that needs work. I would like to write a second userland scheduler that uses a more fair-share methodology with an interactivity hint. -Matt Matthew Dillon
From: Evan Dower [email blocked] Subject: scheduler rewrite Date: 2004-12-03 18:01:13 --- Matthew Dillon wrote: > > I would like to write a second userland > scheduler that uses a > more fair-share methodology with an > interactivity hint. That basically sounds like ULE to me. Do you plan to adapt ULE, make something separate but similar, or make something separate and radically different? (I suppose their might be some other in-between options too.) I was actually somewhat surprised by FreeBSD5's abandonment of ULE. I had been using it without any significant problems. Of course, if I was playing music, it sounded bad when I unpacked big port tarballs, but that happens with the old scheduler too. Anyway, I'm just looking for more info about what you're thinking about for the scheduler. Thanks, ===== -- Evan Dower
From: Matthew Dillon [email blocked] Subject: scheduler rewrite Date: 2004-12-03 18:47:45 : :That basically sounds like ULE to me. Do you plan to :adapt ULE, make something separate but similar, or :make something separate and radically different? (I :suppose their might be some other in-between options :too.) I was actually somewhat surprised by FreeBSD5's :abandonment of ULE. I had been using it without any :significant problems. Of course, if I was playing :music, it sounded bad when I unpacked big port :tarballs, but that happens with the old scheduler too. :Anyway, I'm just looking for more info about what :you're thinking about for the scheduler. : :Thanks, : :===== :-- :Evan Dower No, we won't be adopting ULE. I've written a dozen schedulers over the last 20 years, I can do a much better job IMHO then ULE. There have been discussions about the scheduler on this list in the past. Basically it is a two-stage job. The first stage would be to create an API to allow different userland schedulers to be loaded on-the-fly (on a live system), and possibly even allow multiple schedulers to operate in parallel. This is possible because everything winds up being scheduled by LWKT at the lowest level anyway. That is, the userland scheduler is only determining when user processes run and on what cpu they run and is not actually responsible for the mechanics of running the processes. The second stage would be to then write a new scheduler using the API. LWKT itself uses a strict fixed priority model and round-robins tasks running at the same priority. This is the best model to use for kernel threads (interrupts, software interrupts, protocol threads, etc. 'user' threads usually have the lowest priority). -Matt Matthew Dillon
From: Antonio Vargas [email blocked] Subject: Re: scheduler rewrite Date: 2004-12-07 17:34:58 On Fri, 3 Dec 2004 10:47:45 -0800 (PST), Matthew Dillon wrote: > : > :That basically sounds like ULE to me. Do you plan to > > > :adapt ULE, make something separate but similar, or > :make something separate and radically different? (I > :suppose their might be some other in-between options > :too.) I was actually somewhat surprised by FreeBSD5's > :abandonment of ULE. I had been using it without any > :significant problems. Of course, if I was playing > :music, it sounded bad when I unpacked big port > :tarballs, but that happens with the old scheduler too. > :Anyway, I'm just looking for more info about what > :you're thinking about for the scheduler. > : > :Thanks, > : > :===== > :-- > :Evan Dower > > No, we won't be adopting ULE. I've written a dozen schedulers > over the last 20 years, I can do a much better job IMHO then ULE. > > There have been discussions about the scheduler on this list in > the past. Basically it is a two-stage job. The first stage would > be to create an API to allow different userland schedulers to be > loaded on-the-fly (on a live system), and possibly even allow multiple > schedulers to operate in parallel. This is possible because everything > winds up being scheduled by LWKT at the lowest level anyway. That is, > the userland scheduler is only determining when user processes run and > on what cpu they run and is not actually responsible for the mechanics > of running the processes. > > The second stage would be to then write a new scheduler using the API. > > LWKT itself uses a strict fixed priority model and round-robins tasks > running at the same priority. This is the best model to use for > kernel threads (interrupts, software interrupts, protocol threads, > etc. 'user' threads usually have the lowest priority). > > > > -Matt > Matthew Dillon > > 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
From: Matthew Dillon [email blocked] Subject: Re: scheduler rewrite Date: 2004-12-07 19:54:45 :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
Half of topic - more explanation available?
Is there an explanation available somewhere about how priorities and nice values as seen in top relate to each other and to priorities you're talking about here?
Also how can I influence process priorities (not nice values) from the commandline (I have no access to the process executables to do it from C)?
Basically I have a foreground process that needs to run at full speed as soon as the 'operator' touches the keyboard or touch screen. All CPU consuming background processes have to immediatly slow down at that time. Once the operator becomes 'idle' the background processes have to go back to full speed. Playing with the nice values doesn't do quickly enough what I want. The background processes only slows down if the foreground process is working 'hard enough'.
It`s called a Desktop
This is exactly what all programs should do on any desktop unless you physically alter a given process to not give up the processor eg nice values.
I don't understand
I run a compilation in an xterm, and switch to Mozilla while having gkrellm running and some oggs playing in XMMS (not counting things like Xserver, window manager, syslog, esd, ...), when a new mail arrives. So what should run at full speed now and block the others? And should the compilation pause until I stop web browsing? And XMMS? I really don't understand.
Anyway, your ideal desktop system already exists: it's called Microsoft Windows 3.11.
Its all about priorities
So, nothing should "block the others".
ULE
from Mr Dillon himself
What's your point?
He's totally right, isn't he?
He's always right, except wit
He's always right, except with his grammar, apparently. (then vs than)