From nobody Mon Jan 26 23:13:04 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f0PTn2yMWz6Pmcp; Mon, 26 Jan 2026 23:13:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0PTm6ttmz3SWV; Mon, 26 Jan 2026 23:13:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 60QND4bD036540; Tue, 27 Jan 2026 01:13:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 60QND4bD036540 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 60QND4G2036539; Tue, 27 Jan 2026 01:13:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 27 Jan 2026 01:13:04 +0200 From: Konstantin Belousov To: Marius Strobl Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: e769bc771843 - main - sym(4): Employ memory barriers also on x86 Message-ID: References: <69778ef9.39b4d.5c480abe@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0PTm6ttmz3SWV On Mon, Jan 26, 2026 at 09:30:58PM +0100, Marius Strobl wrote: > On Mon, Jan 26, 2026 at 06:34:49PM +0200, Konstantin Belousov wrote: > > On Mon, Jan 26, 2026 at 03:57:45PM +0000, Marius Strobl wrote: > > > The branch main has been updated by marius: > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=e769bc77184312b6137a9b180c97b87c0760b849 > > > > > > commit e769bc77184312b6137a9b180c97b87c0760b849 > > > Author: Marius Strobl > > > AuthorDate: 2026-01-26 13:58:57 +0000 > > > Commit: Marius Strobl > > > CommitDate: 2026-01-26 15:54:48 +0000 > > > > > > sym(4): Employ memory barriers also on x86 > > > > > > In an MP world, it doesn't hold that x86 requires no memory barriers. > > It does hold. x86 is much more strongly ordered than all other arches > > we currently support. > > If it does hold, then why is atomic_thread_fence_seq_cst() employing > a StoreLoad barrier even on amd64? > I agree that x86 is more strongly ordered than the other supported > architectures, though. Well, it depends on the purpose. Can you please explain what is the purpose of this specific barrier, and where is the reciprocal barrier for it? Often drivers for advanced devices do need fences. For instance, from my experience with the Mellanox networking cards, there are some structures that are located in regular cacheable memory. The readiness of the structure for the card is indicated by a write to some location. If this location is BAR, then at least on x86 we do not need any barriers. But if it is also in the regular memory, the visibility of writes to the structure before the write to a signalling variable must be enforced. This is done normally by atomic_thread_fence_rel(), which on x86 becomes just compiler barrier, since the ordering is guaranteed by CPU (but not compiler). In this situation, using rmb() (which is fence) really degrades the performance on high rates. > > The panic seen matches the typical scenario of even x86 requiring a > StoreLoad barrier. For the actual usage of these macros, the use of > bus_{space,9}_barrier(9) would be more appropriate, however. On x86, > this translates to a "lock addl $0,mem" for BUS_SPACE_BARRIER_READ, > which probably would also achieve the intended order. I'd much > prefer to just do what Linux still does up until today and be done > with it, though. > > Marius