From owner-freebsd-hackers Tue Jan 25 11:40:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8C1A31534E for ; Tue, 25 Jan 2000 11:40:47 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id MAA11812; Tue, 25 Jan 2000 12:05:07 -0800 (PST) Date: Tue, 25 Jan 2000 12:05:07 -0800 From: Alfred Perlstein To: Matthew Dillon Cc: Scott Hess , freebsd-hackers@FreeBSD.ORG Subject: Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs. Message-ID: <20000125120506.W26520@fw.wintelcom.net> References: <01b601bf6696$60701930$1e80000a@avantgo.com> <200001241939.LAA91219@apollo.backplane.com> <0be801bf6715$601423d0$1e80000a@avantgo.com> <200001251752.JAA04953@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200001251752.JAA04953@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jan 25, 2000 at 09:52:31AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Dillon [000125 11:51] wrote: > > :OK, so let's say I did spend some time implementing it in terms of semget() > :and semop(). Would you be totally apalled if the performance turned out to > :be about the same as using a single socketpair? Do you have a very strong > :feeling that it should be significantly better. [Again, under > :3.4-release.] I don't think I've done anything egregious, but things don't > :seem much better. Unfortunately, I'll have to wait until tomorrow morning > :to rip things out and make a suitable example program for posting. > : > :Actually, the performance profile does seem different (for lower loads, the > :semaphore solution seems more efficient), but the performance limits seem > :much the same between the single socketpair and semaphore versions when I > :starts using 16-20 worker processes. It's possible that I'm doing > :.. > : > :Thanks, > :scott > > Well, when all else fails --- go back to individual pipes. > > What else could be tried... you could try surrounding the read() > with an flock() pair. I don't know if flock() uses the more optimal > wakeup code or not. It doesn't, it wakes all processes blocking on the lock, the flock case could be optimized but doesn't seem to be. I think you probably want to experiment with pools attached to the pipe, and you ought to be using pipe rather than socketpair. Meaning have a group of children share a pipe, but not more than N, where N is where you start to see performance problems. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message