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

John Baldwin jhb at FreeBSD.org
Fri Jul 6 16:31:03 UTC 2018


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)

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


More information about the svn-src-head mailing list