From owner-freebsd-arch Tue Nov 13 13:30:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by hub.freebsd.org (Postfix) with ESMTP id 2005D37B418 for ; Tue, 13 Nov 2001 13:30:09 -0800 (PST) Received: from src-fvzagy98ow5 (pool-63.49.207.166.troy.grid.net [63.49.207.166]) by blount.mail.mindspring.net (8.9.3/8.8.5) with SMTP id QAA01085 for ; Tue, 13 Nov 2001 16:30:06 -0500 (EST) Message-Id: <3.0.6.32.20011113163004.009803c0@imatowns.com> X-Sender: ggombert@imatowns.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 13 Nov 2001 16:30:04 -0500 To: arch@freebsd.org From: Glenn Gombert Subject: RE: Thread scheduling in the kernel Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Well, that's cause I think that there are some basic things that need to= be > decided before we can make the decisisons at the bottom of your e-mail. I > think the first thing is that priorities need to be decided. The real question > there is do we want per-thread priorities or per-ksegroup priorities? If you > go totally with per-thread priorities which you seem to be favoring now= and > just use ksegroup for nice and fixed priorities, then that makes kse= groups > simpler at the expense of complicating KSE scheduling. :) Is not a KSE 'bound' to a particular CPU, with each thread in the KSE given a specific amount of time by the kernel scheduler ??. how does the UTS play in this (other than to sleep and wakeup threads) =85 > If we let each thread have a priority and maintain its own scheduling > parameters then I would be tempted to put threads on the runqueue's rather than > kse's primarily because you then have the problem of having to go update= the > priorities of KSE's all the time when thread priorites change. And since you > want a thread to run as soon as its priority allows, this means changign= the > prioritiy of all KSE's in its group so it gets to run on the first one= that what is the mechanism for this (kernel scheduling ) or does the UTS become involve as well ? What is the impact on performance (if re-scheduling is done on a per-thread basis)=85 > becomes available. This would point to a single priority in the KSE group that > all KSE's share that is the highest priority of all runnable threads. If the > list of runnable threads in the KSE group is priority sorted (as it should be) > this isn't but so difficult as you look at the priority of the thread at= the > head of the list. However, every time that priority changes, you have to= go > shuffle KSE's around on the queue's potentially, rather than just moving that > one thread around on the queue's (or putting it on the queue as the case= may > be). Is not time allocated between Threads in a KSE based upon the total amount of time available to the KSE.. if it is not this way , does not Threads associated with a particular application gain an 'unfair' advantage when it come to running =85 > One comment about preemption: probably what we will go with is only preempting > for real time threads (including interrupt threads) and not preempt time > sharing threads until their quantum is up or they block. The entire concept of > KSE's as I understand it, is to serve as a holder for the quantum so that= we > can give a multithreaded process it's full quantum each go-around even if > threads block in which case we split it across multiple threads. In that case, > I think this might be a resonable model: > I think this will achieve the desired goal of a KSE (preserve quanta for > multithreading time-sharing processes across threads) while still allowing > things like priority propagation and preemption to work smoothly. It's= also > fairly simple. > If you use a priority bias for affinity, then that means you basically have a > constant, say 4 (that is random, prolly not the real value) then you will > basically artificially bump the priority of threads with lastcpu =3D=3D cp= uid by 4 > during your comparison. This means you can stop walking the ksegroup list of > threads when you hit a thread whose priority is more than 4 levels less= than > that of the highest priority thread. Also, the first thread you hit that meets > the affinity requirement is the one you run, this should keep a= (hopefully) > decent bound on the amount of list walking done. If KSE's are bound to a particular CPU, how does this affect KSE's & Threads on different CPU' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message