Date: Mon, 20 Nov 2000 13:10:10 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Scott Hess <scott@avantgo.com> Cc: Julian Elischer <julian@elischer.org>, jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <Pine.SUN.3.91.1001120124743.17356A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.LNX.4.21.0011200935290.13680-100000@river.avantgo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Nov 2000, Scott Hess wrote: > 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. > > Please keep disk-I/O-bound programs in mind. The current (3.x/4.x) > pthreads implementation is horrid for programs bound by disk I/O. If you > have a single multithreaded process doing lots of disk I/Os (let's call it > MySQL), then it effectively becomes seek constrained. Converting from > single disk to a 6 disk hardware RAID only gains perhaps %20 in > throughput, even though throughput should at least double or triple. > > My informal testing under 3.x with a 6 disk striped set indicated that > maximum throughput occurred with 8 seperate processes (running 8 seperate > loads), so long as the CPU didn't become a bottleneck. With 1 disk, the > maximum was more like three processes - but it was still more than the > single process your posting would restrict things to. Presumably more > disks would want more processes, with some upper limit where more > processes don't help. You can't compare one multi-threaded process with our current threads implementation to one KSE/KSEG. With one CPU, and therefore 1 KSE within the KSEG, a thread really blocks in the kernel waiting for disk I/O. Unlike our current threads implementation, when that happens under the KSE implementation, the KSE continues to run by issuing an upcall to the threads library to schedule another thread. This can repeat itself, allowing many threads to be blocked in the kernel waiting for disk I/O, but the KSE will not block unless it runs out of resources (needed to save kernel state for threads blocked in the kernel), is preempted by a higher priority process or kernel thread, or exhausts its quantum. With 2 CPUs, you could have 2 KSEs within the KSEG. Nothing changes except that the KSEG workload is spread across 2 KSEs running on different CPUs. The quantum for the KSEG, regardless of whether there are 1 or more KSEs associated with it, remains the same (I would advocate a separate quantum in this case, but I think I'm outvoted on that front). This is all for PTHREAD_SCOPE_PROCESS threads. PTHREAD_SCOPE_SYSTEM threads will be bound to their own KSEG with one KSE. These will act more like LinuxThreads; when one of these threads block in the kernel, another one will not be executed (because there are no other threads allocated for that KSEG/KSE by the threads library). -- Dan Eischen 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?Pine.SUN.3.91.1001120124743.17356A-100000>