Date: Tue, 13 Nov 2001 16:30:04 -0500 From: Glenn Gombert <ggombert@imatowns.com> To: arch@freebsd.org Subject: RE: Thread scheduling in the kernel Message-ID: <3.0.6.32.20011113163004.009803c0@imatowns.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.6.32.20011113163004.009803c0>