Date: Fri, 6 Jul 2018 12:49:28 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: "rgrimes@freebsd.org" <rgrimes@freebsd.org> Cc: Oliver Pinter <oliver.pinter@hardenedbsd.org>, Hans Petter Selasky <hselasky@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include Message-ID: <alpine.BSF.2.21.999.1807061245580.2934@desktop> In-Reply-To: <201807062200.w66M0ecL054312@pdx.rh.CN85.dnsmgr.net> References: <201807062200.w66M0ecL054312@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Jul 2018, Rodney W. Grimes wrote: >> On Friday, July 6, 2018, 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 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 rgrimes@freebsd.org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.21.999.1807061245580.2934>