From owner-freebsd-smp Tue Jun 22 9:19:29 1999 Delivered-To: freebsd-smp@freebsd.org Received: from systemics.com (menger.ai [209.88.68.41]) by hub.freebsd.org (Postfix) with ESMTP id 7531B14E8D for ; Tue, 22 Jun 1999 09:19:19 -0700 (PDT) (envelope-from iang@systemics.com) Received: (from iang@localhost) by systemics.com (8.8.8/8.8.8) id MAA15934 for freebsd-smp@FreeBSD.ORG; Tue, 22 Jun 1999 12:18:55 -0400 (AST) (envelope-from iang) Date: Tue, 22 Jun 1999 12:18:55 -0400 (AST) From: Ian Grigg Message-Id: <199906221618.MAA15934@systemics.com> To: freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? Reply-To: iang@systemics.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Heh. That wouldn't be very symmetric... > > > > No, but having processor affinity would be quite nice. There's > > nothing wrong with MP. > > Processor affinity is more than nice. Work I've done on large HP boxes > indicate that by putting producer/consumer processes on the same processor > one avoids a lot of cache coherency issues, and increases bandwidth > considerably. Admittedly, this is not true of all applications, but > having the ability to have two or more processes share a processor can go > a long way towards tuning application performance. Are you making the assumption that the two processes are sharing memory for IPC? Or, maybe kernel threads? If not, I don't understand how you improve cache coherency with separate data sets. > I would suggest an > ioctl or other API type interface, with a userland tool to assist ... But, I agree with the general context. Processor affinity is nice, but should only be an option on top of SMP. I'd rather have a good SMP than an MP any day. iang To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message