From: "Andreas Hindborg (Samsung)" <nmi@metaspace.dk>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Damien.LeMoal@wdc.com, alex.gaynor@gmail.com, axboe@kernel.dk,
benno.lossin@proton.me, bjorn3_gh@protonmail.com,
boqun.feng@gmail.com, gary@garyguo.net, gost.dev@samsung.com,
hare@suse.de, hch@lst.de, kbusch@kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
lsf-pc@lists.linux-foundation.org, ojeda@kernel.org,
rust-for-linux@vger.kernel.org, wedsonaf@gmail.com,
willy@infradead.org
Subject: Re: [RFC PATCH 06/11] rust: apply cache line padding for `SpinLock`
Date: Fri, 23 Feb 2024 12:29:40 +0100 [thread overview]
Message-ID: <87y1b7a994.fsf@metaspace.dk> (raw)
In-Reply-To: <20230503120354.534136-1-aliceryhl@google.com>
Hi Alice,
Alice Ryhl <aliceryhl@google.com> writes:
> On Wed, 3 May 2023 11:07:03 +0200, Andreas Hindborg <a.hindborg@samsung.com> wrote:
>> The kernel `struct spinlock` is 4 bytes on x86 when lockdep is not enabled. The
>> structure is not padded to fit a cache line. The effect of this for `SpinLock`
>> is that the lock variable and the value protected by the lock will share a cache
>> line, depending on the alignment requirements of the protected value. Aligning
>> the lock variable and the protected value to a cache line yields a 20%
>> performance increase for the Rust null block driver for sequential reads to
>> memory backed devices at 6 concurrent readers.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
>
> This applies the cacheline padding to all spinlocks unconditionally.
> It's not clear to me that we want to do that. Instead, I suggest using
> `SpinLock<CachePadded<T>>` in the null block driver to opt-in to the
> cache padding there, and let other drivers choose whether or not they
> want to cache pad their locks.
I was going to write that this is not going to work because the compiler
is going to reorder the fields of `Lock` and put the `data` field first,
followed by the `state` field. But I checked the layout, and it seems
that I actually get the `state` field first (with an alignment of 4), 60
bytes of padding, and then the `data` field (with alignment 64).
I am wondering why the compiler is not reordering these fields? Am I
guaranteed that the fields will not be reordered? Looking at the
definition of `Lock` there does not seem to be anything that prevents
rustc from swapping `state` and `data`.
>
> On Wed, 3 May 2023 11:07:03 +0200, Andreas Hindborg <a.hindborg@samsung.com> wrote:
>> diff --git a/rust/kernel/cache_padded.rs b/rust/kernel/cache_padded.rs
>> new file mode 100644
>> index 000000000000..758678e71f50
>> --- /dev/null
>> +++ b/rust/kernel/cache_padded.rs
>>
>> +impl<T> CachePadded<T> {
>> + /// Pads and aligns a value to 64 bytes.
>> + #[inline(always)]
>> + pub(crate) const fn new(t: T) -> CachePadded<T> {
>> + CachePadded::<T> { value: t }
>> + }
>> +}
>
> Please make this `pub` instead of just `pub(crate)`. Other drivers might
> want to use this directly.
Alright.
>
> On Wed, 3 May 2023 11:07:03 +0200, Andreas Hindborg <a.hindborg@samsung.com> wrote:
>> diff --git a/rust/kernel/sync/lock/spinlock.rs b/rust/kernel/sync/lock/spinlock.rs
>> index 979b56464a4e..e39142a8148c 100644
>> --- a/rust/kernel/sync/lock/spinlock.rs
>> +++ b/rust/kernel/sync/lock/spinlock.rs
>> @@ -100,18 +103,20 @@ unsafe impl super::Backend for SpinLockBackend {
>> ) {
>> // SAFETY: The safety requirements ensure that `ptr` is valid for writes, and `name` and
>> // `key` are valid for read indefinitely.
>> - unsafe { bindings::__spin_lock_init(ptr, name, key) }
>> + unsafe { bindings::__spin_lock_init((&mut *ptr).deref_mut(), name, key) }
>> }
>>
>> + #[inline(always)]
>> unsafe fn lock(ptr: *mut Self::State) -> Self::GuardState {
>> // SAFETY: The safety requirements of this function ensure that `ptr` points to valid
>> // memory, and that it has been initialised before.
>> - unsafe { bindings::spin_lock(ptr) }
>> + unsafe { bindings::spin_lock((&mut *ptr).deref_mut()) }
>> }
>>
>> + #[inline(always)]
>> unsafe fn unlock(ptr: *mut Self::State, _guard_state: &Self::GuardState) {
>> // SAFETY: The safety requirements of this function ensure that `ptr` is valid and that the
>> // caller is the owner of the mutex.
>> - unsafe { bindings::spin_unlock(ptr) }
>> + unsafe { bindings::spin_unlock((&mut *ptr).deref_mut()) }
>> }
>> }
>
> I would prefer to remain in pointer-land for the above operations. I
> think that this leads to core that is more obviously correct.
>
> For example:
>
> ```
> impl<T> CachePadded<T> {
> pub const fn raw_get(ptr: *mut Self) -> *mut T {
> core::ptr::addr_of_mut!((*ptr).value)
> }
> }
>
> #[inline(always)]
> unsafe fn unlock(ptr: *mut Self::State, _guard_state: &Self::GuardState) {
> unsafe { bindings::spin_unlock(CachePadded::raw_get(ptr)) }
> }
> ```
Got it 👍
BR Andreas
next prev parent reply other threads:[~2024-02-26 9:02 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-03 9:06 [RFC PATCH 00/11] Rust null block driver Andreas Hindborg
2023-05-03 9:06 ` [RFC PATCH 01/11] rust: add radix tree abstraction Andreas Hindborg
2023-05-03 10:34 ` Benno Lossin
2023-05-05 4:04 ` Matthew Wilcox
2023-05-05 4:49 ` Andreas Hindborg
2023-05-05 5:28 ` Matthew Wilcox
2023-05-05 6:09 ` Christoph Hellwig
2023-05-05 8:33 ` Chaitanya Kulkarni
2023-05-03 9:06 ` [RFC PATCH 02/11] rust: add `pages` module for handling page allocation Andreas Hindborg
2023-05-03 12:31 ` Benno Lossin
2023-05-03 12:38 ` Benno Lossin
2023-05-05 4:09 ` Matthew Wilcox
2023-05-05 4:42 ` Andreas Hindborg
2023-05-05 5:29 ` Matthew Wilcox
2023-05-03 9:07 ` [RFC PATCH 03/11] rust: block: introduce `kernel::block::mq` module Andreas Hindborg
2023-05-08 12:29 ` Benno Lossin
2023-05-11 6:52 ` Sergio González Collado
2024-01-23 14:03 ` Andreas Hindborg (Samsung)
2024-01-12 9:18 ` Andreas Hindborg (Samsung)
2024-01-23 16:14 ` Benno Lossin
2024-01-23 18:39 ` Andreas Hindborg (Samsung)
2024-01-25 9:26 ` Benno Lossin
2024-01-29 14:14 ` Andreas Hindborg (Samsung)
2023-05-03 9:07 ` [RFC PATCH 04/11] rust: block: introduce `kernel::block::bio` module Andreas Hindborg
2023-05-08 12:58 ` Benno Lossin
2024-01-11 12:49 ` Andreas Hindborg (Samsung)
2024-02-28 14:31 ` Andreas Hindborg
2024-03-09 12:30 ` Benno Lossin
2023-05-03 9:07 ` [RFC PATCH 05/11] RUST: add `module_params` macro Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 06/11] rust: apply cache line padding for `SpinLock` Andreas Hindborg
2023-05-03 12:03 ` Alice Ryhl
2024-02-23 11:29 ` Andreas Hindborg (Samsung) [this message]
2024-02-26 9:15 ` Alice Ryhl
2023-05-03 9:07 ` [RFC PATCH 07/11] rust: lock: add support for `Lock::lock_irqsave` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 08/11] rust: lock: implement `IrqSaveBackend` for `SpinLock` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 09/11] RUST: implement `ForeignOwnable` for `Pin` Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 10/11] rust: add null block driver Andreas Hindborg
2023-05-03 9:07 ` [RFC PATCH 11/11] rust: inline a number of short functions Andreas Hindborg
2023-05-03 11:32 ` [RFC PATCH 00/11] Rust null block driver Niklas Cassel
2023-05-03 12:29 ` Andreas Hindborg
2023-05-03 13:54 ` Niklas Cassel
2023-05-03 16:47 ` Bart Van Assche
2023-05-04 18:15 ` Andreas Hindborg
2023-05-04 18:36 ` Bart Van Assche
2023-05-04 18:46 ` Andreas Hindborg
2023-05-04 18:52 ` Keith Busch
2023-05-04 19:02 ` Jens Axboe
2023-05-04 19:59 ` Andreas Hindborg
2023-05-04 20:55 ` Jens Axboe
2023-05-05 5:06 ` Andreas Hindborg
2023-05-05 11:14 ` Miguel Ojeda
2023-05-04 20:11 ` Miguel Ojeda
2023-05-04 20:22 ` Jens Axboe
2023-05-05 10:53 ` Miguel Ojeda
2023-05-05 12:24 ` Boqun Feng
2023-05-05 13:52 ` Boqun Feng
2023-05-05 19:42 ` Keith Busch
2023-05-05 21:46 ` Boqun Feng
2023-05-05 19:38 ` Bart Van Assche
2023-05-05 3:52 ` Christoph Hellwig
2023-06-06 13:33 ` Andreas Hindborg (Samsung)
2023-06-06 14:46 ` Miguel Ojeda
2023-05-05 5:28 ` Hannes Reinecke
2023-05-07 23:31 ` Luis Chamberlain
2023-05-07 23:37 ` Andreas Hindborg
[not found] ` <2B3CA5F1CCCFEAB2+20230727034517.GB126117@1182282462>
2023-07-28 6:49 ` Andreas Hindborg (Samsung)
2023-07-31 14:14 ` Andreas Hindborg (Samsung)
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=87y1b7a994.fsf@metaspace.dk \
--to=nmi@metaspace.dk \
--cc=Damien.LeMoal@wdc.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gost.dev@samsung.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.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