Date: Fri, 18 Dec 1998 03:44:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: michaelh@cet.co.jp (Michael Hancock) Cc: vanmaren@fast.cs.utah.edu, tlambert@primenet.com, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <199812180344.UAA20700@usr06.primenet.com> In-Reply-To: <Pine.BSF.3.95LJ1.1b3.981218112129.22058A-100000@sv01.cet.co.jp> from "Michael Hancock" at Dec 18, 98 11:26:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Switching between two threads in the same process is faster, > > all things being equal, because you don't have to flush the > > TLB on the x86 (reload CR3). But you are right -- just selecting > > a random thread probably won't necessarially pick one from the > > same process. > > How much more would it cost to have the scheduler favor a thread in a > process that had another thread block while a lot of quantum was left, > over an async call gate implementation? The quantum clock is reset on a context switch, so it would cost you the ability to run any other program on the system until such time as all threads in that program block or ran to the point of quantum expiration, at which point an involuntary context switch would occur. Of course, given an involuntary context switch occurring, there's no reason why the scheduler wouldn't potentially pick a different thread in the same process, so you could get CPU starvation of all other programs that way, too. > > Of course, the global kernel lock is going to start causing serious > > performance problems before much longer. I've already seen cases > > where the system time approached 50% on my dual Pentium II. > > I think we should go to subsystem coarse-grained locks as a first step and > allow different SMP approaches within each subsystem. No. We need to address the problem (kernel reentrancy), not the symptom (waiting on locks for a non-reentrant kernel). Kernel threads are an inelegant kludge if they are being used to address the kernel reentrancy issue; that issue is much better addressed by maintaining a pool of contexts within the kernel on which user space processes make system call requests and the kernel executes this on behalf of the user process. The problem of SMP scaling is totally seperate. If you consider CPU cycles as a consumable resource, it's a pretty simple problem to deal with allocation of CPU cycles to code that wants to run. First, you run all of the kernel code that's ready to run, then you run all of the user space code that wants to run. CPU cycles can be spread wherever they are needed, without regard to whether it's kernel or user space code that's being run. Typically, you would expect that, barring system work, the CPU's are running in user space code. Better to not address SMP scalability through explicit thread to CPU mapping, except as necessary to minimize bus contention between the processors (affinity, etc.). At this point, the whole value to "how many threads in a process" has more to do with the concurrency that a process can achieve, than in the method by which concurrency is achieved. The idea of "kernel threads allocated to a process" is not a policy or specific implementation concern, but rather a measure of how aggressively a given process will compete for quantum against other processes in the system. 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?199812180344.UAA20700>