Date: Mon, 20 Nov 2000 09:45:53 -0800 (PST) From: Scott Hess <scott@avantgo.com> To: Julian Elischer <julian@elischer.org> Cc: jasone@FreeBSD.ORG, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <Pine.LNX.4.21.0011200935290.13680-100000@river.avantgo.com> In-Reply-To: <3A192821.13463950@elischer.org>
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. 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. [No, I don't have the bandwidth to contribute work at this time. I might be able to scrape together some time to characterize the issue more precisely, though, if I knew that my results were going to get folded in. My main goal is that after everything is said and done, there isn't a huge hole intentionally designed into the system!] Later, scott 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). 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.LNX.4.21.0011200935290.13680-100000>