[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <khepgn2kxjm7tcfntoxuocalp6zesrpjbsurwi6ynjetwxocdp@mrhw7g7wa7mh>
Date: Fri, 16 May 2025 12:17:37 +0200
From: Jan Kara <jack@...e.cz>
To: Davidlohr Bueso <dave@...olabs.net>
Cc: brauner@...nel.org, jack@...e.cz, viro@...iv.linux.org.uk,
mcgrof@...nel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] fs/buffer: optimize discard_buffer()
On Thu 15-05-25 10:39:25, Davidlohr Bueso wrote:
> While invalidating, the clearing of the bits in discard_buffer()
> is done in one fully ordered CAS operation. In the past this was
> done via individual clear_bit(), until e7470ee89f0 (fs: buffer:
> do not use unnecessary atomic operations when discarding buffers).
> This implies that there were never strong ordering requirements
> outside of being serialized by the buffer lock.
>
> As such relax the ordering for archs that can benefit. Further,
> the implied ordering in buffer_unlock() makes current cmpxchg
> implied barrier redundant due to release semantics. And while in
> theory the unlock could be part of the bulk clearing, it is
> best to leave it explicit, but without the double barriers.
>
> Signed-off-by: Davidlohr Bueso <dave@...olabs.net>
Yes, we just want to clear several flag bits as cheaply as possible while
other tasks can be modifying other flags. You change makes sense so feel
free to add:
Reviewed-by: Jan Kara <jack@...e.cz>
Honza
> ---
> fs/buffer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 210b43574a10..f0fc78910abf 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1616,8 +1616,8 @@ static void discard_buffer(struct buffer_head * bh)
> bh->b_bdev = NULL;
> b_state = READ_ONCE(bh->b_state);
> do {
> - } while (!try_cmpxchg(&bh->b_state, &b_state,
> - b_state & ~BUFFER_FLAGS_DISCARD));
> + } while (!try_cmpxchg_relaxed(&bh->b_state, &b_state,
> + b_state & ~BUFFER_FLAGS_DISCARD));
> unlock_buffer(bh);
> }
>
> --
> 2.39.5
>
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists