On Fri, 6 Jul 2018, Rodney W. Grimes wrote:
On Friday, July 6, 2018, 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 linux case the lock instructions are runtime patchable. They have so
called altinstruction facility, which able to detect specific conditions -
in this case up vs smp - and in up case the locks are replaced with simple
nops or one multi word nop when the instruction longer than 1 byte.
Thank you for this information, which lends credibilty to the fact that
these LOCK instructions may not be as cheap as some think they are,
as why would the Linux people bother with run time patching code if
infact it was that cheap.
This code to patch in linux dates from a time when lock was incredibly
expensive and SMP was rare. On x86 of the era lock would actually assert
a bus lock on the north bridge. Today lock prefix without contention is
not particularly expensive, about the same as a divide, as long as the
line is in cache. If it is not in cache, the memory access is an order of
magnitude more expensive than the atomic. If it is contended then you
have different problems.
My feeling is that these days more people overestimate the cost of atomics
than under estimate. It's really the _sharing_ that is expensive.
Thanks,
Jeff
I would not want to take that approach though.
... commit diff text deleted ...
--
Rod Grimes rgri...@freebsd.org
_______________________________________________
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"
