Date: Tue, 25 Jan 2000 12:05:07 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Scott Hess <scott@avantgo.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Performance issue with rfork() and single socketpairs versus multiple socketpairs. Message-ID: <20000125120506.W26520@fw.wintelcom.net> In-Reply-To: <200001251752.JAA04953@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jan 25, 2000 at 09:52:31AM -0800 References: <01b601bf6696$60701930$1e80000a@avantgo.com> <200001241939.LAA91219@apollo.backplane.com> <0be801bf6715$601423d0$1e80000a@avantgo.com> <200001251752.JAA04953@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000125120506.W26520>