On 7/6/18 8:52 AM, Rodney W. Grimes wrote: >> On Fri, Jul 6, 2018 at 9:32 AM, Rodney W. Grimes < >> free...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
