From nobody Tue Jul 15 22:00:03 2025 X-Original-To: dev-commits-src-main@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 4bhY5Y09YYz61gN8; Tue, 15 Jul 2025 22:00: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 4bhY5X2Rf2z3C6K; Tue, 15 Jul 2025 22:00: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 56FM038g064494; Wed, 16 Jul 2025 01:00:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 56FM038g064494 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 56FM03OV064493; Wed, 16 Jul 2025 01:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Jul 2025 01:00:03 +0300 From: Konstantin Belousov To: Mark Johnston Cc: Gleb Smirnoff , alc@freebsd.org, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: fad79db40505 - main - vm_pageout: Remove a volatile qualifier from some vm_domain members Message-ID: References: <202507151519.56FFJ4FS013944@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4bhY5X2Rf2z3C6K X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Tue, Jul 15, 2025 at 05:44:13PM -0400, Mark Johnston wrote: > On Tue, Jul 15, 2025 at 11:04:57PM +0300, Konstantin Belousov wrote: > > On Tue, Jul 15, 2025 at 01:24:36PM -0400, Mark Johnston wrote: > > > On Tue, Jul 15, 2025 at 09:40:18AM -0700, Gleb Smirnoff wrote: > > > > On Tue, Jul 15, 2025 at 03:19:04PM +0000, Mark Johnston wrote: > > > > M> The branch main has been updated by markj: > > > > M> > > > > M> URL: https://cgit.FreeBSD.org/src/commit/?id=fad79db405052f3faad7184ea2c8bfe9f92a700d > > > > M> > > > > M> commit fad79db405052f3faad7184ea2c8bfe9f92a700d > > > > M> Author: Mark Johnston > > > > M> AuthorDate: 2025-07-15 15:16:40 +0000 > > > > M> Commit: Mark Johnston > > > > M> CommitDate: 2025-07-15 15:16:40 +0000 > > > > M> > > > > M> vm_pageout: Remove a volatile qualifier from some vm_domain members > > > > M> > > > > M> These are always accessed using atomic(9) intrinsics, so do not need the > > > > M> qualifier. No functional change intended. > > > > M> > > > > M> Reviewed by: alc, kib > > > > M> MFC after: 2 weeks > > > > M> Sponsored by: Modirum MDPay > > > > M> Sponsored by: Klara, Inc. > > > > M> Differential Revision: https://reviews.freebsd.org/D51322 > > > > > > > > What's the benefit of removing the qualifiers? They act as documentation > > > > and they match atomic(9) prototypes. To me this looks like removing a > > > > const qualifier with a reasoning that we use the variable only as an > > > > argument to functions that have const qualifier. > > > > > > Note that I updated the comments as well to indicate that accesses to > > > the fields should be done through atomic(9), so the documentation is > > > preserved. > > > > > > The reason atomic(9) prototypes include the volatile qualifier is to > > > permit their use with volatile-qualified variables without a cast, not > > > because the interface expects only volatile-qualified parameters. > > > > > > More generally, I believe that new code should always avoid using > > > volatile to provide any kind of synchronization, ignoring the case of > > > accesses to memory mapped with non-default attributes. atomic(9) > > > intrinsics should be used where they are needed, and some comments > > > should explain the synchronization protocol if it's not obvious. > > > > Hmm, when I wrote atomic_load/store(), volatile casts were used to utilize > > compiler-specific semantic of volatile accesses, that happens to match > > what loads and stores should do (access that place now). I.e. it is not > > for the allowance to use volatile-qualified locations, but to provide > > the C11-compatible semantic. > > My understanding is that C11 atomic ops take volatile-qualified > parameters for the reason I gave above. There is a note in the standard > which suggests this: > > NOTE Many operations are volatile-qualifed. The ‘‘volatile as device > register’’ semantics have not changed in the standard. This qualifcation > means that volatility is preserved when applying these operations to > volatile objects. > > I see similar hints here, but I don't know what source this is based on: > https://en.cppreference.com/w/c/atomic/atomic_load.html I answered more to the Gleb' question, about making atomically accessed locations volatile. Yes, volatile (and const for load since some time) are used to allow also accessing volatile-qualified atomics. But it is not to provide atomicity properties through volatile properties. > > > After stating that, it is clear why qualifying the vars with volatile > > is not what we want: the semantic of volatile is compiler-dependent, > > and it only happens to match what is really used for code. Atomics > > loads and stores do provide the primitive ops we need, and hide the > > compiler-specific implementation under. > > > > I.e., volatile should *not* be used.