From owner-freebsd-hackers Tue Jan 25 1:21:16 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id EAA7B14F23 for ; Tue, 25 Jan 2000 01:21:13 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 132; Tue, 25 Jan 2000 01:17:16 -0800 Message-ID: <0be801bf6715$601423d0$1e80000a@avantgo.com> From: "Scott Hess" To: "Matthew Dillon" Cc: References: <01b601bf6696$60701930$1e80000a@avantgo.com> <200001241939.LAA91219@apollo.backplane.com> Subject: Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs. Date: Tue, 25 Jan 2000 01:20:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew Dillon" wrote: > :Unfortunately, I've found that having a group of processes reading from a > :group of socketpairs has better performance than having them all read from > :a single socketpair. I've been unable to determine why. > > The problem is that when you have N processes waiting on a single > socket and you write to the socket, all N processes will wake up even > though only one will get the data you wrote. > As an alternative to socket pairs, I would consider using SysV shared > memory and SysV semaphores. 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 something which makes the system intrinsically top out at a given point - tomorrow I'm going to attempt to make the minimal changes necessary to adapt multiple socketpairs to the existing system, in the hope that either the multiple socketpair version is faster in context, or it's slower living in this set of code than in the original prototype. Thanks, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message