From owner-freebsd-net@FreeBSD.ORG Thu Jan 10 21:12:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6802F6F7 for ; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 45B61948 for ; Thu, 10 Jan 2013 21:12:40 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE1B7B96B; Thu, 10 Jan 2013 16:12:39 -0500 (EST) From: John Baldwin To: Konstantin Belousov Subject: Re: To SMP or not to SMP Date: Thu, 10 Jan 2013 12:17:07 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301091554.43618.jhb@freebsd.org> <20130109234215.GK2561@kib.kiev.ua> In-Reply-To: <20130109234215.GK2561@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301101217.07833.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 10 Jan 2013 16:12:39 -0500 (EST) Cc: Barney Cordoba , freebsd-net@freebsd.org, erichsfreebsdlist@alogt.com, jack.vogel@gmail.com, atkin901@gmail.com, sthaug@nethelp.no X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:12:40 -0000 On Wednesday, January 09, 2013 06:42:15 PM Konstantin Belousov wrote: > On Wed, Jan 09, 2013 at 03:54:43PM -0500, John Baldwin wrote: > > On Wednesday, January 09, 2013 10:00:31 am Barney Cordoba wrote: > > > --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > > > > From: sthaug@nethelp.no > > > > Subject: Re: To SMP or not to SMP > > > > To: erichsfreebsdlist@alogt.com > > > > Cc: barney_cordoba@yahoo.com, freebsd-net@freebsd.org, > > > > jack.vogel@gmail.com, atkin901@gmail.com > > > > > > Date: Wednesday, January 9, 2013, 9:32 AM > > > > > > > > > > 4BSD runs pretty well with > > > > > > > > an SMP kernel. I can test ULE and compare > > > > > > > > > > easily. A no SMP kernel is problematic as the igb > > > > > > > > driver doesn't seem > > > > > > > > > > to work and my onboard NICs are, sadly, igb. > > > > > > > > > > this is bad luck. I know of the kernels as I have had > > > > > > > > SMP and single > > > > > > > > > CPU machines since 4.x times. > > > > > > > > I have had igb working with both SMP and non-SMP kernel for > > > > at least a > > > > year or two, 8.x-STABLE. No specific problems. > > > > > > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > > > > > Maybe a problem with "legacy interrupts" on more modern processors? > > > I'm using an E5520 and while the NIC inits ok, it just doesnt seem to > > > gen interrupts. I can't spend much time debugging it.... > > > > > > I notice that HAMMER kernels use MSI/X interrupts whether SMP is > > > enabled or not, while i386 kernels seem to require APIC. Is there some > > > physical reason for this? > > > > MSI always requires APIC. (MSI interrupts on x86 have to be delivered to > > a local APIC, no way to send them to 8259As.) You can build an i386 > > kernel with device apic but without 'options SMP' which is akin to > > leaving SMP out of an amd64 kernel. > > > > Removing SMP on x86 changes the following things: > > - Spin mutexes just disable interrupts on the local CPU and don't use any > > atomic operations at all. All other lock types work the same. > > - atomic operations don't use the "lock" prefix so are cheaper. However, the > > atomic op used for locks (cmpxchg) has an implicit "lock" prefix, so > > this isn't but so much of a gain. > > I do not think that cmpxchg uses implicit lock, and Intel IA32 SDM supports > this view. The absense of the lock prefix makes the instruction decode > faster, and removes the locked bus cycle. > > It is xchg which is implicitely locked, but we no longer use it for unlock. Ah, that's true, for some reason I thought cmpxchg was like xchg in this matter. -- John Baldwin