From owner-freebsd-hackers Mon Jan 24 11:41: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1190715C4E for ; Mon, 24 Jan 2000 11:40:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA91219; Mon, 24 Jan 2000 11:39:29 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Jan 2000 11:39:29 -0800 (PST) From: Matthew Dillon Message-Id: <200001241939.LAA91219@apollo.backplane.com> To: "Scott Hess" Cc: Subject: Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs. References: <01b601bf6696$60701930$1e80000a@avantgo.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I've found an odd performance issue that I cannot explain. I'm using :socketpairs to communicate with multiple rfork(RFPROC) processes. :Initially, I used a seperate socketpair to communicate requests to each :... : :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. I've reduced the :problem down to a simple program, included as an attachment (sorry about :that). The results of two runs of the program: 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. This is very similar to the select() problem -- N processes select()ing on the same descriptor (typically a socket listen descriptor), new connection comes in, all N processes are woken up even though only one's accept() will succeed. As an alternative to socket pairs, I would consider using SysV shared memory and SysV semaphores. Under -current you can use shared file mmap()'s with MAP_NOSYNC as an alternative to using SysV shared memory, but the SysV shared memory calls will be more portable. ( When messing with SysV shared memory the system utility 'ipcs -a' comes in useful ). man -k shm man ipcs -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message