From owner-svn-src-all@freebsd.org Fri Jul 6 16:54:46 2018 Return-Path: Delivered-To: svn-src-all@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 5F054103AB3B; Fri, 6 Jul 2018 16:54:46 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1A498AEE3; Fri, 6 Jul 2018 16:54:45 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w66Gshos053187; Fri, 6 Jul 2018 09:54:43 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w66GshSt053186; Fri, 6 Jul 2018 09:54:43 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201807061654.w66GshSt053186@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include In-Reply-To: <1f87b7ba-3b59-e710-00b0-91a4b0e4e5b4@FreeBSD.org> To: John Baldwin Date: Fri, 6 Jul 2018 09:54:43 -0700 (PDT) CC: rgrimes@freebsd.org, Warner Losh , Hans Petter Selasky , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 16:54:46 -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) My add probably needs to be && !defined > > 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. Which means when I compiled UP before I had nothing, and now this adds useless LOCK perfixes in place of . -- Rod Grimes rgrimes@freebsd.org