From: "Paul E. McKenney" <paulmck@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Philipp Stanner" <pstanner@redhat.com>,
"Kent Overstreet" <kent.overstreet@linux.dev>,
"Boqun Feng" <boqun.feng@gmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, llvm@lists.linux.dev,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Andrea Parri" <parri.andrea@gmail.com>,
"Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Nicholas Piggin" <npiggin@gmail.com>,
"David Howells" <dhowells@redhat.com>,
"Jade Alglave" <j.alglave@ucl.ac.uk>,
"Luc Maranget" <luc.maranget@inria.fr>,
"Akira Yokosawa" <akiyks@gmail.com>,
"Daniel Lustig" <dlustig@nvidia.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
kent.overstreet@gmail.com,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
elver@google.com, "Mark Rutland" <mark.rutland@arm.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [WIP 0/3] Memory model and atomic API in Rust
Date: Mon, 8 Apr 2024 09:55:23 -0700 [thread overview]
Message-ID: <fec60bba-e414-43d1-bc3e-870f5ffe4626@paulmck-laptop> (raw)
In-Reply-To: <ZhQVHZnU3beOhEGU@casper.infradead.org>
On Mon, Apr 08, 2024 at 05:02:37PM +0100, Matthew Wilcox wrote:
> On Mon, Mar 25, 2024 at 10:44:43AM -0700, Linus Torvalds wrote:
> > So I actually think most compiler people are perfectly fine with the
> > kernel model of mostly doing 'volatile' not on the data structures
> > themselves, but as accesses through casts.
> >
> > It's very traditional C, and there's actually nothing particularly odd
> > about it. Not even from a compiler standpoint.
> >
> > In fact, I personally will argue that it is fundamentally wrong to
> > think that the underlying data has to be volatile. A variable may be
> > entirely stable in some cases (ie locks held), but not in others.
> >
> > So it's not the *variable* (aka "object") that is 'volatile', it's the
> > *context* that makes a particular access volatile.
> >
> > That explains why the kernel has basically zero actual volatile
> > objects, and 99% of all volatile accesses are done through accessor
> > functions that use a cast to mark a particular access volatile.
>
> What annoys me is that 'volatile' accesses have (at least) two distinct
> meanings:
> - Make this access untorn
> - Prevent various optimisations (code motion,
> common-subexpression-elimination, ...)
>
> As an example, folio_migrate_flags() (in mm/migrate.c):
>
> if (folio_test_error(folio))
> folio_set_error(newfolio);
> if (folio_test_referenced(folio))
> folio_set_referenced(newfolio);
> if (folio_test_uptodate(folio))
> folio_mark_uptodate(newfolio);
>
> ... which becomes...
>
> 1f: f6 c4 04 test $0x4,%ah
> 22: 74 05 je 29 <folio_migrate_flags+0x19>
> 24: f0 80 4f 01 04 lock orb $0x4,0x1(%rdi)
> 29: 48 8b 03 mov (%rbx),%rax
> 2c: a8 04 test $0x4,%al
> 2e: 74 05 je 35 <folio_migrate_flags+0x25>
> 30: f0 80 4d 00 04 lock orb $0x4,0x0(%rbp)
> 35: 48 8b 03 mov (%rbx),%rax
> 38: a8 08 test $0x8,%al
> 3a: 74 05 je 41 <folio_migrate_flags+0x31>
> 3c: f0 80 4d 00 08 lock orb $0x8,0x0(%rbp)
>
> In my ideal world, the compiler would turn this into:
>
> newfolio->flags |= folio->flags & MIGRATE_MASK;
>
> but because folio_test_foo() and folio_set_foo() contain all manner of
> volatile casts, the compiler is forced to do individual tests and sets.
>
> Part of that is us being dumb; folio_set_foo() should be __folio_set_foo()
> because this folio is newly allocated and nobody else can be messing
> with its flags word yet. I failed to spot that at the time I was doing
> the conversion from SetPageFoo to folio_set_foo.
>
> But if the compiler people could give us something a little more
> granular than "scary volatile access disable everything", that would
> be nice. Also hard, because now you have to figure out what this new
> thing interacts with and when is it safe to do what.
OK, I will bite...
Why not accumulate the changes in a mask, and then apply the mask the
one time? (In situations where __folio_set_foo() need not apply.)
If it turns out that we really do need a not-quite-volatile, what exactly
does it do? You clearly want it to be able to be optimized so as to merge
similar accesses. Is there a limit to the number of accesses that can
be merged or to the region of code over which such merging is permitted?
Either way, how is the compiler informed of these limits?
(I admit that I am not crazy about this sort of proposal, but that might
have something to do with the difficulty of repeatedly convincing
people that volatile is necessary and must be retained...)
Thanx, Paul
next prev parent reply other threads:[~2024-04-08 16:55 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 23:38 [WIP 0/3] Memory model and atomic API in Rust Boqun Feng
2024-03-22 23:38 ` [WIP 1/3] rust: Introduce atomic module Boqun Feng
2024-03-22 23:52 ` Andrew Lunn
2024-03-23 0:03 ` Boqun Feng
2024-03-23 19:13 ` Miguel Ojeda
2024-03-23 19:30 ` Boqun Feng
2024-03-23 9:58 ` Alice Ryhl
2024-03-23 14:10 ` Andrew Lunn
2024-03-23 19:09 ` Miguel Ojeda
2024-03-26 5:56 ` Trevor Gross
2024-03-22 23:38 ` [WIP 2/3] rust: atomic: Add ARM64 fetch_add_relaxed() Boqun Feng
2024-03-22 23:38 ` [WIP 3/3] rust: atomic: Add fetch_sub_release() Boqun Feng
2024-03-22 23:57 ` [WIP 0/3] Memory model and atomic API in Rust Kent Overstreet
2024-03-23 0:12 ` Linus Torvalds
2024-03-23 0:21 ` Kent Overstreet
2024-03-23 0:36 ` Linus Torvalds
2024-03-23 2:07 ` Kent Overstreet
2024-03-23 2:26 ` Boqun Feng
2024-03-23 2:33 ` Kent Overstreet
2024-03-23 2:57 ` Boqun Feng
2024-03-23 3:10 ` Kent Overstreet
2024-03-23 3:51 ` Boqun Feng
2024-03-23 4:16 ` Kent Overstreet
2024-03-25 13:56 ` Philipp Stanner
2024-03-25 17:44 ` Linus Torvalds
2024-03-25 18:59 ` Kent Overstreet
2024-03-25 19:44 ` Linus Torvalds
2024-03-25 21:14 ` Kent Overstreet
2024-03-25 21:37 ` Boqun Feng
2024-03-25 22:09 ` Kent Overstreet
2024-03-25 22:38 ` Boqun Feng
2024-03-25 23:02 ` Kent Overstreet
2024-03-25 23:41 ` Boqun Feng
2024-03-26 0:05 ` Dr. David Alan Gilbert
2024-03-26 0:36 ` Kent Overstreet
2024-03-26 1:35 ` Dr. David Alan Gilbert
2024-03-26 3:28 ` Kent Overstreet
2024-03-26 2:51 ` Boqun Feng
2024-03-26 3:49 ` Linus Torvalds
2024-03-26 14:35 ` Dr. David Alan Gilbert
2024-03-27 16:16 ` comex
2024-03-27 18:50 ` Kent Overstreet
2024-03-27 19:07 ` Linus Torvalds
2024-03-27 19:41 ` Kent Overstreet
2024-03-27 20:45 ` Linus Torvalds
2024-03-27 21:41 ` Kent Overstreet
2024-03-27 22:57 ` Linus Torvalds
2024-03-27 23:35 ` Kent Overstreet
2024-03-27 21:21 ` Boqun Feng
2024-03-27 21:49 ` Kent Overstreet
2024-03-27 22:26 ` Boqun Feng
2024-03-27 21:56 ` comex
2024-03-27 22:02 ` comex
2024-04-05 17:13 ` Philipp Stanner
2024-04-08 16:02 ` Matthew Wilcox
2024-04-08 16:55 ` Paul E. McKenney [this message]
2024-04-08 17:03 ` Matthew Wilcox
2024-04-08 18:47 ` Paul E. McKenney
2024-04-09 0:58 ` Kent Overstreet
2024-04-09 4:47 ` Paul E. McKenney
2024-04-08 17:01 ` Linus Torvalds
2024-04-08 18:14 ` Al Viro
2024-04-08 20:05 ` Linus Torvalds
2024-03-23 21:40 ` comex
2024-03-24 15:22 ` Alan Stern
2024-03-24 17:37 ` comex
2024-03-23 0:15 ` Boqun Feng
2024-03-23 0:49 ` Boqun Feng
2024-03-23 1:42 ` Kent Overstreet
2024-03-23 14:29 ` Andrew Lunn
2024-03-23 14:41 ` Boqun Feng
2024-03-23 14:55 ` Boqun Feng
2024-03-25 10:44 ` Mark Rutland
2024-03-25 20:59 ` Boqun Feng
2024-04-09 10:50 ` Peter Zijlstra
2024-04-16 18:12 ` Boqun Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fec60bba-e414-43d1-bc3e-870f5ffe4626@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=a.hindborg@samsung.com \
--cc=akiyks@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=elver@google.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=kent.overstreet@gmail.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=luc.maranget@inria.fr \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=npiggin@gmail.com \
--cc=ojeda@kernel.org \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=pstanner@redhat.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=wedsonaf@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).