Date: Fri, 6 Jul 2018 09:31:01 -0700 From: John Baldwin <jhb@FreeBSD.org> To: rgrimes@freebsd.org, Warner Losh <imp@bsdimp.com> Cc: 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: <1f87b7ba-3b59-e710-00b0-91a4b0e4e5b4@FreeBSD.org> In-Reply-To: <201807061552.w66Fq0FX052931@pdx.rh.CN85.dnsmgr.net> References: <201807061552.w66Fq0FX052931@pdx.rh.CN85.dnsmgr.net>
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) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1f87b7ba-3b59-e710-00b0-91a4b0e4e5b4>