Date: Wed, 04 Dec 1996 18:55:30 -0500 From: Bakul Shah <bakul@plexuscom.com> To: Terry Lambert <terry@lambert.org> Cc: julian@whistle.com, cracauer@wavehh.hanse.de, nawaz921@cs.uidaho.EDU, freebsd-hackers@freebsd.org Subject: Re: clone()/rfork()/threads (Re: Inferno for FreeBSD) Message-ID: <199612042355.SAA16383@chai.plexuscom.com> In-Reply-To: Your message of "Wed, 04 Dec 1996 15:00:18 MST." <199612042200.PAA17332@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Because each kernel thread is a "kernel schedulable entity". Quantums > are given to "kernel schedulable entities", they are not given to > thread groups. > [...] > > This is a "fairness" issue. > > If I, as the scheduler, have a "next quantum" to give away, fairness > dictates that I select the next process in the highest priority ready > to run queue to give it to. If, instead of treating a thread *as* a schedulable entity, you allow a set of threads to *belong to* the same schedulable entity, you can be fair and get around the problems you mentined. The kernel runs threads from the same group as long as their quantum has not expired and atleast one of them is runnable. When it switches back to the same group, it will use a FIFO scheme: the first runnable thread to give up the processor is the first to run. [Didn't the Thoth OS have something like this?] As an example, if threads A B and C belong to the same schedulable entity, then when A blocks, B gets to run provided the quantum is not used up. When B blocks, C will run. Now if C hogs the CPU, it will be kicked out at the end of the quantum. The next time this group is run, A will be run (if it has unblocked) since it was the first to give up the CPU. This way even a compute bound thread will not hog the processor nor will it be allowed to be unfair to threads in other groups. > Now consider that the purpose of kernel threading is to allow kernel > threads to be scheduled on different CPU's. In other words, if A > has an affinity for CPU1, then B will have a negative affinity for > CPU1 (a positive affinity for CPUn, n!=1) proportional to A's affinity; > any other approach, and you will not achieve maximal concurrency in > the given application. > Suddenly, the scheduler becomes so complicated, that the benefit of > having multiple CPUs is diminished! The above idea can be extended to multi processors fairly easily. Though multi-processor schedulers that can also do realtime scheduling (and appropriately deal with priority inversion) are not easy. No time to respond to some of your other points :-( -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612042355.SAA16383>