From owner-svn-src-head@freebsd.org Fri Jul 6 22:52:10 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AC371037ED9 for ; Fri, 6 Jul 2018 22:52:10 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9D1E73609 for ; Fri, 6 Jul 2018 22:52:09 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by mail-pf0-x242.google.com with SMTP id y24-v6so9476412pfe.12 for ; Fri, 06 Jul 2018 15:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jroberson-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=bLSWGPCZinbZ3Gslot+IPY9U8dCqhDlBF/rWuA2N8gU=; b=hwATApUZcUxOmQe98bcUoHJbdUESFZ8IxZaXX7bxcO7kNW75a3jJidsArTbbRllnlt uJLua/4Hl+TQIb2UghX4K/WDXC+z+hs15wwGZz+WFCR4s25iSm8760Vn3pd7ugkgwJCX XbW5f6amOjcUdFH5qzBUMDTs4WVbRu7l+TC0cyqP9DwNMxIIGKXkkwQ4qc8ZEQsZPmID ND9unWoFtRSYeC+N36mpzO2x+5MZQZuoGfuO0tLVUoz2gbx/GMmDZfA2WVnZVTmMGs9X 04gD77icbHQJUzUti0pnbcW+jgIZ37g+5dCkVyXilDQzvNCC2kPUmnNmNBiTeZCa8uNX Z0gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=bLSWGPCZinbZ3Gslot+IPY9U8dCqhDlBF/rWuA2N8gU=; b=BERf1mdjq5DCpQNSqyCZDyPazn+80Ty//AmmOqzibXBDW6snvy4QhO1Pl+eMzkjXgP wRfE7UIOWObIdNRHPIEeCKGx4M11BqcQwkMkqnzWwym5k8mjSva2BfDT8ehA5jBeg/UR eAMPIUvjj5jVml/v0rveh5cxmrCEJNNqHicOE81UMML5xDihhJ+ozeF1+TSKr5IFk1GJ CM1A60FmkzURc4sLoFhbNsTyXMeH/qwxwSsjMBoFhXRTHqXARGmkTx2/W9Z04MetQs6Z R2N1ZzChrqCbbd72ShYZLSfslzMtIB9LEtWvHrSsWiEBFRPwJ8Sh8deDgAy2poa5aRJt Wung== X-Gm-Message-State: APt69E1DCZ+jJUeOIoKKIpy2pAw04Ov2DDSgh2FQ5NwfFyhFs6jwUSnl I2kOVivCmulltOEAZ3HQy3+0Mw== X-Google-Smtp-Source: AAOMgpfBS0fOqqPQi9bUd+2Q7gtdpKDW460rw7GV8aHz/668WgLuDqEwR77WNn/ZYbIeO9LOOLGWaQ== X-Received: by 2002:a65:6491:: with SMTP id e17-v6mr10850686pgv.44.1530917528859; Fri, 06 Jul 2018 15:52:08 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by smtp.gmail.com with ESMTPSA id k71-v6sm22939785pga.62.2018.07.06.15.52.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 15:52:08 -0700 (PDT) Date: Fri, 6 Jul 2018 12:49:28 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "rgrimes@freebsd.org" cc: Oliver Pinter , Hans Petter Selasky , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include In-Reply-To: <201807062200.w66M0ecL054312@pdx.rh.CN85.dnsmgr.net> Message-ID: References: <201807062200.w66M0ecL054312@pdx.rh.CN85.dnsmgr.net> User-Agent: Alpine 2.21.999 (BSF 260 2018-02-26) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 22:52:10 -0000 On Fri, 6 Jul 2018, Rodney W. Grimes wrote: >> On Friday, July 6, 2018, Rodney W. Grimes >> 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 >