From owner-svn-src-all@freebsd.org Tue Dec 11 00:14:08 2018 Return-Path: Delivered-To: svn-src-all@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 AF5151337681 for ; Tue, 11 Dec 2018 00:14:08 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E721752FF for ; Tue, 11 Dec 2018 00:14:07 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-it1-x143.google.com with SMTP id x19so880858itl.1 for ; Mon, 10 Dec 2018 16:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wb0RP5ZsF2sDXJ0YfirrjzHS7A44BgChCT5qwoJsveA=; b=DmVN5NauGZ+jvqQraokql6PWxSnfw+wABn65ffl6MjB8mBe8+zFmpBtTasaMl6VA23 MKiBqNSRlFdbA3vDQoNGqJap7TlmpG9sC8pUvmGrHxraW5VCoB1JRW/qeSEK+fhEjqJo s5uV80nm2VxNPfL+cZp0BFm6O0l2TTT5bJPvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wb0RP5ZsF2sDXJ0YfirrjzHS7A44BgChCT5qwoJsveA=; b=tJNFAmANw/u5UZEatChlJ4+l3D1dZNjP/bRi0rrRTudY/HL6H0apEoqhuVPTUthU4g a1tsL90Ef2YpLMZKo1nCrfm/qs0E6EWND3isl22NqvSoKIvnIdAkoL2fkXStIdsAuO67 SvVNs8kqhEyy1CKmS/OEyKd/X0z+MsZ6CaLg0nIgFVZg4T0zAMSCqVzwyJyf+9rcbevs d7+ltRZ3FcecJ2RXto/ix+zhzD/viFqrNF8e0veRx0fo5ESF3IbRatSstuvCsc/ogbIm 9muJfXEE15tBh5VPt3fHxsABJ3qfVrYZVRjy7kMRYVJ0pnfdW+8bhYUd+GCq3PjI9CGe N2XQ== X-Gm-Message-State: AA+aEWa4QYfsqHDz+TVniOdkUxOHmi1Hwb49rNxjLGxMkWo78Jr26zW6 pM09vp7RZx5/ETKHmqmrktNirLNv6viBEA4Lh4Gbfg== X-Google-Smtp-Source: AFSGD/XGKZkwq7AB9MLWIJ7OpsScyZFhV1zdh3KI+gtCEKJfDeOXX12llskZ+NOreaoo52qkrajtQ3lNNPF8OGnRshE= X-Received: by 2002:a24:1152:: with SMTP id 79mr465294itf.167.1544487246869; Mon, 10 Dec 2018 16:14:06 -0800 (PST) MIME-Version: 1.0 References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org> <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> <1544486233.1860.343.camel@freebsd.org> In-Reply-To: <1544486233.1860.343.camel@freebsd.org> From: Kevin Bowling Date: Mon, 10 Dec 2018 17:13:55 -0700 Message-ID: Subject: Re: svn commit: r341682 - head/sys/sys To: ian@freebsd.org Cc: John Baldwin , Warner Losh , mjguzik@gmail.com, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , scottl@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9E721752FF X-Spamd-Result: default: False [1.36 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_SHORT(0.48)[0.478,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[kev009.com]; NEURAL_SPAM_MEDIUM(0.69)[0.688,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[kev009.com:~]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[3.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[8]; R_DKIM_PERMFAIL(0.00)[kev009.com]; NEURAL_SPAM_LONG(0.25)[0.252,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(0.25)[ip: (4.14), ipnet: 2607:f8b0::/32(-1.52), asn: 15169(-1.28), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 00:14:08 -0000 Right we are talking about a polyfill for systems that have 1-2 cores in practice. You're not going to crank high parallelism on these global locks in practice and the common lock may help performance due to cache residence for all we know. This is a lot of ballyhoo for a decision that should favor the reduction of complexity, clean KPIs, and overwhelming majority of machines that have 64b atomics, not scattering ifdefs in the code for niche performance. Regards, Kevin On Mon, Dec 10, 2018 at 4:57 PM Ian Lepore wrote: > > On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote: > > On 12/8/18 7:43 PM, Warner Losh wrote: > > > > > > > > > > > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > m wrote: > > > > > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > m > wrote: > > > > > > > > > > > Fully satisfying solution would be that all architectures get > > > 64-bit > > > > ops, even if in the worst case they end up taking a lock. > > > Then > > > > subsystems would not have to ifdef on anything. However, > > > there > > > > was some opposition to this proposal and I don't think this > > > is > > > > important enough to push. > > > > > > Mateusz, > > > > > > Who is opposing this particular polyfill solution? Scott Long > > > brought > > > up a situation in driver development where this would be useful > > > as > > > well. The polyfills lower the cognitive load and #ifdef soup > > > which > > > are the right call here regardless of performance on toy ports. > > > > > > > > > I don't recall seeing the opposition either. It would have to be a > > > global lock for all 64bit atomics.... but I think it would only be > > > 2 atomics on those architectures. > > It would have to be a spin lock, so in the case of unrl you would be > > trading > > an operation on one of N regular mutexes for a single spin lock that > > was > > also contested by other things. This would be pretty crappy. For > > drivers > > that aren't actually used on platforms without 32-bit atomics we can > > simply > > not build them in sys/modules/Makefile or not put them in > > GENERIC. For > > something in the core kernel like unrl I think we will have to do > > what > > Mateusz has done here. > > > > On a single-core system all you need to implement 64-bit atomics in the > kernel is to disable interrupts around using normal load/store > operations on the values. Do we have any platforms that are SMP but > don't have hardware primitives for 64-bit atomics? > > -- Ian