From owner-svn-src-head@freebsd.org Fri Jul 6 16:31:03 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF4451038005; Fri, 6 Jul 2018 16:31:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61440898FE; Fri, 6 Jul 2018 16:31:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 4186F10AFCD; Fri, 6 Jul 2018 12:31:02 -0400 (EDT) Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include To: rgrimes@freebsd.org, Warner Losh References: <201807061552.w66Fq0FX052931@pdx.rh.CN85.dnsmgr.net> Cc: Hans Petter Selasky , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org From: John Baldwin Message-ID: <1f87b7ba-3b59-e710-00b0-91a4b0e4e5b4@FreeBSD.org> Date: Fri, 6 Jul 2018 09:31:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201807061552.w66Fq0FX052931@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 06 Jul 2018 12:31:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:31:03 -0000 On 7/6/18 8:52 AM, Rodney W. Grimes wrote: >> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < >> freebsd@pdx.rh.cn85.dnsmgr.net> wrote: >> >>>> Author: hselasky >>>> Date: Fri Jul 6 10:13:42 2018 >>>> New Revision: 336025 >>>> URL: https://svnweb.freebsd.org/changeset/base/336025 >>>> >>>> Log: >>>> Make sure kernel modules built by default are portable between UP and >>>> SMP systems by extending defined(SMP) to include defined(KLD_MODULE). >>>> >>>> This is a regression issue after r335873 . >>>> >>>> Discussed with: mmacy@ >>>> Sponsored by: Mellanox Technologies >>> >>> Though this fixes the issue, it also means that now when >>> anyone intentionally builds a UP kernel with modules >>> they are getting SMP support in the modules and I am >>> not sure they would want that. I know I don't. >>> >> >> >> On UP systems, these additional opcodes are harmless. They take a few extra >> cycles (since they lock an uncontested bus) and add a couple extra memory >> barriers (which will be NOPs). On MP systems, atomics now work by default. >> Had we not defaulted like this, all modules built outside of a kernel build >> env would have broken atomics. Given that (a) the overwhelming majority >> (99% or more) is SMP and (b) the MP code merely adds a few cycles to what's >> already a not-too-expensive operation, this was the right choice. >> >> It simply doesn't matter for systems that are relevant to the project >> today. While one could try to optimize this a little (for example, by >> having SMP defined to be 0 or 1, say, and changing all the ifdef SMP to if >> (defined(SMP) && SMP != 0)), it's likely not going to matter enough for >> anybody to make the effort. UP on x86 is simply not relevant enough to >> optimize for it. Even in VMs, people run SMP kernels typically even when >> they just allocate one CPU to the VM. >> >> So while we still support the UP config, and we'll let people build >> optimized kernels for x86, we've flipped the switch from pessimized for SMP >> modules to pessimized for UP modules, which seems like quite the reasonable >> trade-off. >> >> Were it practical to do so, I'd suggest de-orbiting UP on x86. However, >> it's a lot of work for not much benefit and we'd need to invent much crazy >> to get there. > > Trivial to fix this with > +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE) || !defined(KLD_UP_MODULES) This is not worth it. Note that we already use LOCK always in userland which is probably far more prevalent than the use in modules. Previously atomics in modules were _function calls_ just to avoid the LOCK. Having the LOCK prefix present even on UP is probably far more efficient than a function call. -- John Baldwin