Date: Mon, 20 Nov 2000 21:56:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: scott@avantgo.com (Scott Hess) Cc: julian@elischer.org (Julian Elischer), jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <200011202156.OAA02067@usr08.primenet.com> In-Reply-To: <Pine.LNX.4.21.0011200935290.13680-100000@river.avantgo.com> from "Scott Hess" at Nov 20, 2000 09:45:53 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> I have seen the notion of limiting KSE's to the number of CPUs mentioned a > number of times on the arch and smp lists. This is presumably done to > maximize performance of CPU-bound and network-I/O-bound programs. A KSE is a "reservation for quantum". It is effectively a quantum holder. The quantum can be spread against multiple threads in user space. Except on multiple CPUs, which would permit multiple KSEs, all CPU utilization is serialized through the scheduler anyway. What a KSE buys you is thread group locality for context switcthes, which is something that is computationally difficult to achieve satisfactorily in a Linux or SVR4 approach to kernel threading, since it can quickly lead to starvation deadlock, where a threaded process gets affinity preference for its ready-to-run threads in the scheduler, thus starving everything else in the scheduler queue which is not the threaded process. In other words, it's incredibly hard to achieve affinity after you have broken the quantum-process accounting connection. KSEs preserve this connection. This typically means that, if you are attempting to use multiple threads to unfairly compete for quantum, you will have to follow the scheduler priority rules instead (many threads programmers use threads in an attempt to subvert the scheduler policy without resorting to increased priviledges; this is wrong). So your examples are all workable, merely by providing multiple user space threads. > On Mon, 20 Nov 2000, Julian Elischer wrote: > > A KSEG can only have as a maximum N KSEs associated with it, where N is > > the number of processors, (unless artificially reduced by a lower > > concurency declaration). (you said this but only indirectly). In > > general, KSEs are each assigned to a processor. They do not in general > > move between processors unless some explicit adjustment is being > > made(*), and as a general rule, two KSEs will not be assigned to the > > same processor. (in some transitional moments this may be allowed to > > briefly happen) This in general if you run a KSEC on the same KSE it was > > run on last time, you should be on the same processor, > > (and get any affinity advantages that might exist). I really, really disagree with Julian's statement about not assigning multiple KSEs to the same processor. There are perfectly valid loading reasons (e.g. two KSEs that each take 30% of the CPU, cooperating, with one CPU with a process that takse 90% of the CPU, while the other CPU is only at 60% utilization, etc.). There is also the PTHREAD_SCOPE_SYSTEM scheduling; one can easily conceive of a multithreading application, where one thread in the total list of threads needs to run with a real time priority to insure rapid interacative response, with metered intervals. One example would be a DVD player, where the rendering needs to occur at fixed intervals with no latency, whereas the fuffer-refill from the DVDROM, and the control functons for the program, overall, can run in normal priority threads. So I think there is a good argument for needing to support in the kernel the idea of multiple KSEs on a single processor; I understand Julian's anxiety about what this could do to the complexity of the sleep queues, but with respect to everyone, if the task's too complex, then stay out of the kernel (it's not too complex for Julian, it's just I don't think that the kernel should have to be written on the computer science equivalent of a 6th grade reading leveli: if it can't be understood by everyone, too bad: most people couldn't tell you how the ignition system in their car works, either). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200011202156.OAA02067>