Date: Fri, 18 Dec 1998 19:13:30 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <tlambert@primenet.com> Cc: vanmaren@fast.cs.utah.edu, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <Pine.BSF.3.95LJ1.1b3.981218183741.24098A-100000@sv01.cet.co.jp> In-Reply-To: <199812180344.UAA20700@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. I think the scheduler in BSD favors I/O bound processes anyway so the process should get another quantum soon. Long running CPU bound processes get lower priorities but if they don't get enough CPU then the priority is boosted. The Async call gate does sound interesting for process contention threads. It seems intuitive that a process should be allowed to use its threads to use up as much of its quantum as possible. But instead of an async call gate you should probably be thinking in terms of "scheduler activations" where the kernel informs the Pthreads library that it's about to block a thread. The library can immediately schedule a new Pthreads thread. This is what Digital UNIX does. Solaris 2.5 would just block and programmers had to allocate extra kernel entities (LWPs?) to maintain process concurrency. > > > 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). I think that can be worked on gradually per-subsystem so why not get the immediate gratification of a coarse grained system while you're working towards that goal. Making the kernel reentrant is a lot of work and presumably the guy working on the network code will be different from the guy working on the fs code. > 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. With Pthreads you have the options: pthread_attr_setscope( ..., PTHREAD_SCOPE_PROCESS); or pthread_attr_setscope( ..., PTHREAD_SCOPE_SYSTEM); You have to implement one, but it'd be nice to have both. Process contention is good for most apps, but if you need more predictability then you need system contention where the threads will compete with threads in other processes. Regards, Mike Hancock 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?Pine.BSF.3.95LJ1.1b3.981218183741.24098A-100000>