Date: Fri, 6 Jul 2018 09:54:43 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: John Baldwin <jhb@freebsd.org> Cc: rgrimes@freebsd.org, Warner Losh <imp@bsdimp.com>, Hans Petter Selasky <hselasky@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include Message-ID: <201807061654.w66GshSt053186@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1f87b7ba-3b59-e710-00b0-91a4b0e4e5b4@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <null>. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201807061654.w66GshSt053186>