From owner-freebsd-net@FreeBSD.ORG Wed Jan 9 23:42:23 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 A97F36E1; Wed, 9 Jan 2013 23:42:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 049C03D9; Wed, 9 Jan 2013 23:42:22 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r09NgGCg016497; Thu, 10 Jan 2013 01:42:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r09NgGCg016497 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r09NgFV6016496; Thu, 10 Jan 2013 01:42:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 10 Jan 2013 01:42:15 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: To SMP or not to SMP Message-ID: <20130109234215.GK2561@kib.kiev.ua> References: <1357743631.24911.YahooMailClassic@web121605.mail.ne1.yahoo.com> <201301091554.43618.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVcIhgQsEzAXu06J" Content-Disposition: inline In-Reply-To: <201301091554.43618.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home 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: Wed, 09 Jan 2013 23:42:23 -0000 --EVcIhgQsEzAXu06J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > --- On Wed, 1/9/13, sthaug@nethelp.no wrote: > >=20 > > > 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,=20 > 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.=20 > > > > >=20 > > > > this is bad luck. I know of the kernels as I have had > > > SMP and single > > > > CPU machines since 4.x times. > > >=20 > > > 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. > > >=20 > > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > >=20 > >=20 > > 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.... > >=20 > > 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? >=20 > MSI always requires APIC. (MSI interrupts on x86 have to be delivered to= a=20 > local APIC, no way to send them to 8259As.) You can build an i386 kernel= with=20 > device apic but without 'options SMP' which is akin to leaving SMP out of= an=20 > amd64 kernel. >=20 > 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 th= is > 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. --EVcIhgQsEzAXu06J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7gBUAAoJEJDCuSvBvK1Bp5MP/0sfhpAgyKogFDXv/hB+WRnF G5RcN/Hid8J7LAO9y5j1OeWs1mL/nR7zQDknqICE4qx5cl/W7hAqm1KR2Tkxc/bo luStOwjl2ktf0PA45istAvxf8Md+z+9HMPZCR8unnQkm3WijKdtns7FKgM9XMCa/ /XW1p5slRNwCoo24JVC9asLdS3ZareVLSo9L92b1BFxV4RHQtDxQ4FL/JYngDH2t r3TLS7Zzby9wIWNz+yXqZIzL8VSAkQrsKYjZebfDLbWDuPheIRqA6LX+bZMhe5mf syYcGLV+T9iAptJNmVMYgZjdhqQSlh8Mx+jQ6nt+f6AAjp9Z4Q+HRjIclSiPLnyD 8t2RTlKtJvxE34ByyhD5C04JzyiGXw1U2rQVqLeLEb8HOc9J1qL2cJLuAzxADXu2 TN3f+j8MGx1x4L2hER0vc7uJBpP1sDHKl0SsmFpgkh+rWrnqHEovv+59ZxHjpwSW 8AsulX4u0BqWeBKNlU3lEFiH/1Aly9pwCL/4axus1MzOX4iYh0mSpwE8IAALvBSq FHr71CeBUVDWQ1pGZmmf08v2CTuHD10xk+JFCRja03c6+CvdrDJnnfCCKuKlfiBA mm5cTrFjxxav9K6gg2YOYzTI6iakwreRsgDBdUDfN3qiWGK0obqxpguI/Yji3w6c 2DPvrcZeSsEJh6gAK/KV =vWZT -----END PGP SIGNATURE----- --EVcIhgQsEzAXu06J--