svn commit: r336025 - in head/sys: amd64/include i386/include

[Rodney W. Grimes]

> On 7/6/18 8:52 AM, Rodney W. Grimes wrote:
> >> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes <
> >> freebsd at 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 at freebsd.org