Linux-ARM-Kernel Archive on lore.kernel.org

* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Mark Rutland @ 2024-03-25 10:44 UTC (permalink / raw)
  To: Boqun Feng
  Cc: rust-for-linux, linux-kernel, linux-arch, llvm, Miguel Ojeda,
	Alex Gaynor, Wedson Almeida Filho, Gary Guo, Bj"orn Roy Baron,
	Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
	Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
	David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
	Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
	Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
	Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
	H. Peter Anvin, Catalin Marinas, torvalds, linux-arm-kernel,
	linux-fsdevel
In-Reply-To: <20240322233838.868874-1-boqun.feng@gmail.com>

On Fri, Mar 22, 2024 at 04:38:35PM -0700, Boqun Feng wrote:
> Hi,
> 
> Since I see more and more Rust code is comming in, I feel like this
> should be sent sooner rather than later, so here is a WIP to open the
> discussion and get feedback.
> 
> One of the most important questions we need to answer is: which
> memory (ordering) model we should use when developing Rust in Linux
> kernel, given Rust has its own memory ordering model[1]. I had some
> discussion with Rust language community to understand their position
> on this:
> 
> 	https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1218407557
> 	https://github.com/rust-lang/unsafe-code-guidelines/issues/476#issue-2001382992
> 
> My takeaway from these discussions, along with other offline discussion
> is that supporting two memory models is challenging for both correctness
> reasoning (some one needs to provide a model) and implementation (one
> model needs to be aware of the other model). So that's not wise to do
> (at least at the beginning). So the most reasonable option to me is:
> 
> 	we only use LKMM for Rust code in kernel (i.e. avoid using
> 	Rust's own atomic).
> 
> Because kernel developers are more familiar with LKMM and when Rust code
> interacts with C code, it has to use the model that C code uses.

I think that makes sense; if nothing else it's consistent with how we handle
the C atomics today.

> And this patchset is the result of that option. I introduced an atomic
> library to wrap and implement LKMM atomics (of course, given it's a WIP,
> so it's unfinished). Things to notice:
> 
> * I know I could use Rust macro to generate the whole set of atomics,
>   but I choose not to in the beginning, as I want to make it easier to
>   review.
> 
> * Very likely, we will only have AtomicI32, AtomicI64 and AtomicUsize
>   (i.e no atomic for bool, u8, u16, etc), with limited support for
>   atomic load and store on 8/16 bits.
> 
> * I choose to re-implement atomics in Rust `asm` because we are still
>   figuring out how we can make it easy and maintainable for Rust to call
>   a C function _inlinely_ (Gary makes some progress [2]). Otherwise,
>   atomic primitives would be function calls, and that can be performance
>   bottleneck in a few cases.

I don't think we want to maintain two copies of each architecture's atomics.
This gets painful very quickly (e.g. as arm64's atomics get patched between
LL/SC and LSE forms).

Can we start off with out-of-line atomics, and see where the bottlenecks are?

It's relatively easy to do that today, at least for the atomic*_*() APIs:

  https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=atomics/outlined&id=e0a77bfa63e7416d610769aa4ab62bc06993ce56

... which IIUC covers the "AtomicI32, AtomicI64 and AtomicUsize" cases you
mention above.

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply