Date: Tue, 15 Jul 2025 17:44:13 -0400 From: Mark Johnston <markj@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Gleb Smirnoff <glebius@freebsd.org>, 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: <aHbLraZ1qk4mSpE7@nuc> In-Reply-To: <aHa0aSgHNlE4NIg4@kib.kiev.ua> References: <202507151519.56FFJ4FS013944@gitrepo.freebsd.org> <aHaEcqEoH9ZpUf7X@cell.glebi.us> <aHaO1DLOvyheNLkr@nuc> <aHa0aSgHNlE4NIg4@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <markj@FreeBSD.org> > > > M> AuthorDate: 2025-07-15 15:16:40 +0000 > > > M> Commit: Mark Johnston <markj@FreeBSD.org> > > > 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 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aHbLraZ1qk4mSpE7>