Date: Tue, 21 Nov 2000 18:24:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@elischer.org (Julian Elischer) Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <200011211824.LAA27595@usr08.primenet.com> In-Reply-To: <3A1A2A26.4CF0B849@elischer.org> from "Julian Elischer" at Nov 20, 2000 11:54:14 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> CC's trimmed, > > which group should stay? SMP or ARCH? ARCH is chartered for the discussion, SMP is where the work is actually geting done. I think that's the reason for the original poster to cross-post. I'll let clearer heads prevail by picking where to sent their response. > there is no reason why ANY KSEG need sto be limitted to one KSE > by the kernel unless there is only one CPU. > The PTHREAD_SCOPE_PROCESS, KSEG may have one or more KSEs > assigned to it depending > on whether the UTS wants to create more or not.... > > Thinking about what Terry said, I guess you could have M>N > (M KSEs, N CPUs) in a KSEG, but I don't think it would be > useful to do so. It lets me have M simultaneous blocking operations outstanding; it's only not useful in the context of KSEGs. I guess we could arrange it this way: (1 KSE, 1 KSEG), (M KSEGs, N CPUs) This should make it more obvious: I want M quanta from N CPUs. Or in other words, I want to compete as M porcesses on this N CPU system. The reason for this is to allow me to control my own interleave; for example, if we look at the "team" or "ddd" programs, both of which use interleaved I/O using multiple processes to improve overall throughput, we see an application where I _do not_ want 2 quanta for 3 threads, with 2 of the threads bound to only one of the quanta: doing that will lose me 25% of my throughput. If you want to visualize the scheduling order, think of a three element braid (braids are neat: the simplest is a three element, and you can think of it as a graph of FIFO queue, two elements at a time). If there is equal work, then the work on each of two elements is going to complete in alternating order, which means that if you have a third element waiting, it will be alternately assigned (ideally; KSEGs break this). I think that perhaps the best use of threading is to try to interleave I/O to ensure against I/O binding. KSEGs seem to be designed with the idea that the threaded application is CPU, not I/O bound, which is where I think the mistake lies. > > > One gross hack might be to limit the number of total KSEs to > > > the number of permitted child processes for a given process, > > > but I'd hesitate to encourage people to use the not generally > > > exposed and non (POSIX) standard interfaces that would be > > > needed for a process to try to do this automatically. > > > > You have to be careful with terminology. If we're going by > > what Jason has defined in his paper, the KSEG is the entity > > that has the quantum, not the KSE. So the KSEGs would be > > limited to the permitted number of child processes. > > yes, but that gives the ability to use M times as much CPU as a > nonthreaded process. If you won't give it to me, I'll just take it, instead, either by using rfork() and a shared memory segment for my global data, which gets me the equivalenet of a threaded environment, for all practical purposes, or I'll just fork() and run multiple instances of myself. Either way, you don't get to tell me not to compete as multiple processes, and I can throw a KSEG based policy out the window, without needing your permission to do it. Worse, there is additional context switch overhead introduced by this (the same reason Linux kernel threads are a bad idea), and everyone gets to pay the penalty for my application. 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-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011211824.LAA27595>