From owner-svn-src-head@freebsd.org Sat Jul 7 01:45:50 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 D7CD810225BC for ; Sat, 7 Jul 2018 01:45:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 697B67B1C1 for ; Sat, 7 Jul 2018 01:45:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x241.google.com with SMTP id v71-v6so9050068itb.3 for ; Fri, 06 Jul 2018 18:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RogtuwQSY2H0fXmOdGiLGetYo5opaRf3mJyf/GYiAkM=; b=x36uRiFzW4h4tn32+x4N+Xjnh4mOMFiE0EZmcpySEHCq+NRzYugBsif1ufMZ9sbmey QL+sZ7bdwX8HkBTw71JPbUdsAYXmTA5QwgpmXNLTU8vdygoicjFZ0Ii0VgVFS8r7oJXL N8iXNuFTrUvGO5Ote9EF/ybJziMshLl7TQCP5DsAdV/YCDJx80BRsnVt9FFXyuBcIINW zS+JsXzxwq0T1WBWMM/hkDPWPzAiSXrZHqaVpEku00beodpeC3C22bxWpFwimAZZNP7g 8Bk04h9qXAUJvoIZ00ImhT4FwqzXqIgzDU8v7h+xPvk3wIC9ZCNxnLvJnrjkIc2omcbq QQpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RogtuwQSY2H0fXmOdGiLGetYo5opaRf3mJyf/GYiAkM=; b=oWuCA642kQs0RODgJHGkw4oYEV3+dhrdoxaRC0Rq4LPAXSOsJyRkTxQO5Qjwypdt8m 2dbApgbsQ23Qw3pa5OdxRfXfU105phDqytCOXSFk/eGBElWobHgvjGBpc/7m8eG644mw Yz5DtVKJnJTJ5gXNO2YUZU9igHVPL4v2BRjRuzp7WAhMPYNL2mb4gGIAUTZK+Mjn/q6A U53aDxuUZbiM9VAXHTn+seMdlbDEIMczeTtc3q0X7oXdumM8OPjCwGfueWI5LaMvYkk/ m++G/iXHJJDAp3FCYmWPCwGb+Dyk08UReVvUeSP/BojWpBI+M12+TRfCBo6gEmfm/7/h yZEQ== X-Gm-Message-State: APt69E1jMJcNgQjZidAHGGrJlJ+kmZGGvnZ4oWaHyenq6diStWsnJcbc MkkTgSboB1ESJB0kW1nNxCdbC40z+lj2W8UpRxiBwg== X-Google-Smtp-Source: AAOMgpfu+SiPkvs0Oh0B9gtyZLkzWGzvmvwE5FtqVoun4KXsXanbM20iLG1bCJNLXZuc8Web8dtwqfZegsi9Npthv+U= X-Received: by 2002:a24:d0d7:: with SMTP id m206-v6mr9544030itg.1.1530927948531; Fri, 06 Jul 2018 18:45:48 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:1183:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 18:45:47 -0700 (PDT) X-Originating-IP: [74.62.67.99] In-Reply-To: References: <201807061013.w66ADgbJ087546@repo.freebsd.org> <201807061532.w66FWPEN052842@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Fri, 6 Jul 2018 19:45:47 -0600 X-Google-Sender-Auth: lgYYUWdW-k0xKJqn7ZKxG-sRH3k Message-ID: Subject: Re: svn commit: r336025 - in head/sys: amd64/include i386/include To: Don Lewis Cc: "Rodney W. Grimes" , Hans Petter Selasky , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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: Sat, 07 Jul 2018 01:45:50 -0000 On Fri, Jul 6, 2018 at 6:06 PM, Don Lewis wrote: > On 6 Jul, Warner Losh wrote: > > On Fri, Jul 6, 2018 at 9:32 AM, 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 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. > > I would distinguish i386 from amd64 here. SMP is pretty rare and exotic > in the i386 world I don't know I'd say that. There's been MP systems widely available since Pentium Pro days. They aren't in laptops, but they were fairly common in i386 land since the mid 90's, especially in server class machines. Not cheap, but not too pricy as to be uncommon.... > I do have one dual socket Pentium 3 machine here and > even though I bought the parts for it used on eBay, it was still pretty > pricey. That purchase was kind of a waste since it was shortly before > the Athlon 64 X2 CPUs were released. > > I still have two viable 32-bit x86 machines here that get frequent > usage. One runs 24x7 and has a Via C3 CPU. I started looking at > migrating off this hardware. To get lower power consumption as well as > ECC RAM I'd probably have to go with one of the Supermicro Atom boards. > Those are pretty expensive, so I'd probably end up spending about half > as much as what it cost to put together my fully-loaded Ryzen machine > last summer. At that price, the payback time from the power savings is > really long. This machine is mostly idle, so I really don't need more > CPU power or RAM. The other machine is my Pentium-M laptop, which is > mostly used for light browsing and as a vnc client when I'm on the road. > Performance is acceptable for those uses. Both machines run stripped > down UP kernels to avoid wasting RAM unnecessarily and to optimize CPU > cycles on the laptop. > > A good reason for continuing UP support on x86 is to make it easy to > test UP builds in the MI parts of the kernel so that we don't break > things for the embedded architectures. Unfortunately "make universe" > currently doesn't have any UP kernels, so I've managed to commit changes > that break UP builds and not known it until I received reports of broken > builds from other users > UP kernels have not changed. The setups that have UP kernels generally need custom ones anyway, since there's so many devices that aren't used. Those setups aren't affected by this change. You raise an interesting point, though: it hasn't been important enough to the project to include a UP kernel in CI testing we've done for years and years... Warner