Date: Tue, 13 Nov 2001 15:47:11 -0500 From: Glenn Gombert <ggombert@imatowns.com> To: freebsd-arch@FreeBSD.org Subject: freebsd-arch@FreeBSD.org Message-ID: <3.0.6.32.20011113154711.009793e0@imatowns.com>
next in thread | raw e-mail | index | archive | help
A couple of questions -- >1/ Since threads running a syscall hit 'sleep' events >the entities on teh sleep queues must be the threads. Will the sleep queues (which mix threads from multiple CPUs) impact performance as the number of threads dramatically increase .. > 2/ the entity that is scheduled onto the run queues is the KSE. > (as the name suggests). Is there a number of threads per KSE that is optimum for performance? will this be impacted by the UpCalls that are made between the Kernel and User land=85..what determines the optimum number of threads to be created pe= r KSE (before another one is created for a particular application).. > 3/ If we have only one run queue, then KSEs for several processors > from the same process, may be on the same queue. > 4/ If threads 'wake up' they are hung of a list of runnable threads > somewhere. This list could be hanging off the process, or the KSE. > actually more likely the KSEgroup than the process but...) .. does not one process serve as a 'container' for one KSEG and multiple KSE and Threads ?? does this process share the time quanta between all its member(s) or is it the job of the UTS to make these type of decisions?? > 5/ If a KSE reaches teh front of the queue, but the process > that is running is not that for which that KSE has some affinity, > does it get out of the way to allow another KSE in the queue > to get run? or does it just run and 'switch' everything over to the new > available processor? Maybe the scheduler looks for the KSE from the same > group, that was assigned to that processor, and runs that, leaving > the original KSE at the head of the queue?=20 > Maybe that happens until all the KSEs in the queue > that were from that group have been run? In this case it becomes possible > to always have a KSE from that group ready... Does the kernel scheduler make the decisions about scheduling (once a Thread has been created) ?..what is the relationship between the UTS and the Kernel Scheduler (from the standpoint of time allocation when it comes to Use's and individual threads)=85 > Maybe the KSE-GROUP is what is put unto the run queue, and KSEs from that > group are put on all processors that look for work, until all of them=20 > have been run? (this would ensure that threads from the same process > would all be run at the same time which is sometimes good, and sometimes > bad, depending on the application. How is the time quanta divided up between KSE's and Threads ??=85who makes the decision when each should be placed on the runqueue and run at a particular time when the responsibility is devided up between the UTS and kernel scheduler=85 > 6/ When a Thread is made runnable it gets (in the present system) a > priority. What priority does a KSE in the run queues have when it has > threads of several differnt priorities? Do we sort them in priority order > and drop the priority of the KSE(group) as we go through them > until we have less priority than some other kse? > 7/ when a KSE runs out of work, how does it decide whether there is work > that should be stolen from a fellow KSE? How does processor affinity > effect this? Is a KSE not bound to a particular processor with the KSEG able to allocate resources between multiple processors? > 8/ If we had per-processor scheduling queues, How would that effect it? > Which element get's put on the queues? Does a KSE > stay on the run queue if it has un=3Drun threads, even when it's running? > How do we handle the arrival of new runnable threads with a KSE > when it's running but a fellow KSE is not runnable. Do we=20 > bump the priority of the other KSE and hand it the new threads? > remember: here are the 4 structures: > proc - owner of all resources (FDs, memory, user creds) except cpu > Ksegroup - owner of all scheduler controlling characteristics > (e.g. nice, realtime, number of processors), N per process. > Owner of stats used for scheduling calculations.=09 > kse - kind of a placeholder. It gets scheduled onto=20 > a processor (by a yet un-named mechaninsm) and provides > cpu-cycles for the execution of 'threads' (see next). > Max. Of one per processor per KSE-group. > thread - The in-kernel incarnation of a user thread that is presently > in the kernel for some reason (e.g. syscall, pagefault, etc) > Holds ALL the state needed to resume after sleeping, and is the > entity that is suspended when the thread hits a 'sleep'. > "unlimmitted" per KSEgroup. probably have a short-term > "favourite" KSE/processor. What is the relationship between processors and processes?? Does not one KSEG distribute multiple KSE's between multiple CPU's? > When a thread blocks, the KSE looks for another thread to run, and if it > doesn't find one, it will create one, and upcall back to the=20 > userland to see if there are more userland threads to run. > (if not, it returns to yield the processor) > The question that has been giving me headaches is the=20 > relationship between these elements, and > the definitions of how these structures are linked up and moved > around to provide fair efficient scheduling. > If a KSE has a high priority thread and a low priority thread > runnable in the kernel, but in reverse order, should it take > the high priority from the higher prio. thread and process both, > or should it order the threads and run teh high prio one first. > In this case what happens whan a higher prio. thread becomes runnable > while one is already running, and if the highest prio thread returns to > userland, should teh processor move to userland to follow it, or > switch to the next priority thread in the kernel.? > Do all threads in the kernel have priority over all threads in userland? > (this might be a reasonable decision). Does the UTS have any input into the priority of how time is apportioned to each individual KSE / Thread in the kernel runqueue??..or is that entirely up to the kernel scheduler =85 In general does the memory allocation/recrimination scheme seem adequate for all the KSE's/Threads that will be created and destroyed with the new implementation=85 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.20011113154711.009793e0>