From owner-svn-src-all@freebsd.org Mon Dec 10 23:57:19 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 2C7C71336ECF for ; Mon, 10 Dec 2018 23:57:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5209B7479C for ; Mon, 10 Dec 2018 23:57:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1544486216; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FMO3ce245ndXUueL0rdDBGQyBCnhZ3h9PjUfz+QdGddsFgmWwKAaDD/e0NDxNfvmh5nqcZJeR9oM3 xbBn0ceI8NH3254Beypg91MSvtARlCDhemoXnvoYHOXLH81+Fn/v7bTB7pTyl/FsxM9xDSGcGh3/3+ SwcLz4M78QMsCKZVfst1x7daJEETFZ+ExCljelsH02MvV4nPPsYumkdWrWCf32ugVQwkMiPK8wb9CY Cq0qwyCk8RNcIP6Q8tTWtVa8SUqjdWprud8Xa2ItwDJJ0kqwt9z4Wa6oNi2mZKvWYPGtyiAzVilwKo UgGCnfamC3a83n7wRZytg6snpzzXcvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=A2KBRWeNKlGo6BKsf/U4OL1ixl56MVn0A+CyT2Qcjn8=; b=mykP0CuNBqvYAuEkQMD2fzVHdG1gKOM0xCicpWxDs+1CeYmSujd3jfX73rKyoZxQx1jZEQ3/ZtJHb Iz/hbhJiXGv0XJwQ5EeUw+UG6FfI8ExZUzzqnb+xmu0S2H9FLaHuziOVlZGYxpCXgrGEfs0K5g30D4 kcKv3QTNRfjTF+cXRmE/Rmr8Lw4VipJsy98FQtIzO9sVNjRLEbUYbjbB+OsDR17GBnfX4DJVd/fWJW +IuITYrGVjNMSUHVyt+Ikq/3f1i0WvZ0owZx7JyJjwkA5v+WrWAXYp1cVjdymczbw06AfC1E2Ik+2j wSx90wpu6115AmXYupigiwC8yA+Lm1w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=A2KBRWeNKlGo6BKsf/U4OL1ixl56MVn0A+CyT2Qcjn8=; b=PQJ45U5TEn4XbJODoPcBpf8rZoCqUbM0GS8Od6FSrBPR0b3t/oWCQ7nxohTy4TK+XlLwrnp/tnNuP mps11qRjFvAWZ2MUApAwvM5taP62tqSNdTlWFdlcBjSE7ioh1+atVvnm3o8/vuiC96WMT9t3mjY4Yp MDYO8NQp8vxZs4w2LYrYPz8lLPf+6qUy5fKHrnsXnbnSW72V5TEZGNVbqZLdna9qwP3yE1jBl8hrTQ sh8scH5/sWxDvc91HsmIKuVMwjf69B5SyYS1JbIYZip+mavoVb5j/w+1TQPVIo94vBOUKJXvMs0tO+ oqO4uyBaeXfxpNpQ6DsNSGgEzaxuW8g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 44bae117-fcd7-11e8-a59a-7b143e15dabc X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 44bae117-fcd7-11e8-a59a-7b143e15dabc; Mon, 10 Dec 2018 23:56:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBANvDEK073321; Mon, 10 Dec 2018 16:57:13 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1544486233.1860.343.camel@freebsd.org> Subject: Re: svn commit: r341682 - head/sys/sys From: Ian Lepore To: John Baldwin , Warner Losh , Kevin Bowling Cc: Mateusz Guzik , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , scottl@freebsd.org Date: Mon, 10 Dec 2018 16:57:13 -0700 In-Reply-To: <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org> <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5209B7479C X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] 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: Mon, 10 Dec 2018 23:57:19 -0000 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