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 <ma...@freebsd.org>
> > > M> AuthorDate: 2025-07-15 15:16:40 +0000
> > > M> Commit: Mark Johnston <ma...@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.
