From: Jan Kara <jack@suse.cz>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: jack@suse.cz, tytso@mit.edu, adilger.kernel@dilger.ca,
brauner@kernel.org, mcgrof@kernel.org, willy@infradead.org,
hare@suse.de, djwong@kernel.org, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/7] fs/buffer: split locking for pagecache lookups
Date: Wed, 16 Apr 2025 11:32:18 +0200 [thread overview]
Message-ID: <bu3ppl5dpe4kf5ykx4mkkg3vccsqkie335oa7wywv6eyvbp2fk@f4yyphvoczty> (raw)
In-Reply-To: <20250415231635.83960-2-dave@stgolabs.net>
On Tue 15-04-25 16:16:29, Davidlohr Bueso wrote:
> Callers of __find_get_block() may or may not allow for blocking
> semantics, and is currently assumed that it will not. Layout
> two paths based on this. The the private_lock scheme will
> continued to be used for atomic contexts. Otherwise take the
> folio lock instead, which protects the buffers, such as
> vs migration and try_to_free_buffers().
>
> Per the "hack idea", the latter can alleviate contention on
> the private_lock for bdev mappings. For reasons of determinism
> and avoid making bugs hard to reproduce, the trylocking is not
> attempted.
>
> No change in semantics. All lookup users still take the spinlock.
>
> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/buffer.c | 41 +++++++++++++++++++++++++----------------
> 1 file changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index b99dc69dba37..c72ebff1b3f0 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -176,18 +176,8 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate)
> }
> EXPORT_SYMBOL(end_buffer_write_sync);
>
> -/*
> - * Various filesystems appear to want __find_get_block to be non-blocking.
> - * But it's the page lock which protects the buffers. To get around this,
> - * we get exclusion from try_to_free_buffers with the blockdev mapping's
> - * i_private_lock.
> - *
> - * Hack idea: for the blockdev mapping, i_private_lock contention
> - * may be quite high. This code could TryLock the page, and if that
> - * succeeds, there is no need to take i_private_lock.
> - */
> static struct buffer_head *
> -__find_get_block_slow(struct block_device *bdev, sector_t block)
> +__find_get_block_slow(struct block_device *bdev, sector_t block, bool atomic)
> {
> struct address_space *bd_mapping = bdev->bd_mapping;
> const int blkbits = bd_mapping->host->i_blkbits;
> @@ -204,7 +194,16 @@ __find_get_block_slow(struct block_device *bdev, sector_t block)
> if (IS_ERR(folio))
> goto out;
>
> - spin_lock(&bd_mapping->i_private_lock);
> + /*
> + * Folio lock protects the buffers. Callers that cannot block
> + * will fallback to serializing vs try_to_free_buffers() via
> + * the i_private_lock.
> + */
> + if (atomic)
> + spin_lock(&bd_mapping->i_private_lock);
> + else
> + folio_lock(folio);
> +
> head = folio_buffers(folio);
> if (!head)
> goto out_unlock;
> @@ -236,7 +235,10 @@ __find_get_block_slow(struct block_device *bdev, sector_t block)
> 1 << blkbits);
> }
> out_unlock:
> - spin_unlock(&bd_mapping->i_private_lock);
> + if (atomic)
> + spin_unlock(&bd_mapping->i_private_lock);
> + else
> + folio_unlock(folio);
> folio_put(folio);
> out:
> return ret;
> @@ -1388,14 +1390,15 @@ lookup_bh_lru(struct block_device *bdev, sector_t block, unsigned size)
> * it in the LRU and mark it as accessed. If it is not present then return
> * NULL
> */
> -struct buffer_head *
> -__find_get_block(struct block_device *bdev, sector_t block, unsigned size)
> +static struct buffer_head *
> +find_get_block_common(struct block_device *bdev, sector_t block,
> + unsigned size, bool atomic)
> {
> struct buffer_head *bh = lookup_bh_lru(bdev, block, size);
>
> if (bh == NULL) {
> /* __find_get_block_slow will mark the page accessed */
> - bh = __find_get_block_slow(bdev, block);
> + bh = __find_get_block_slow(bdev, block, atomic);
> if (bh)
> bh_lru_install(bh);
> } else
> @@ -1403,6 +1406,12 @@ __find_get_block(struct block_device *bdev, sector_t block, unsigned size)
>
> return bh;
> }
> +
> +struct buffer_head *
> +__find_get_block(struct block_device *bdev, sector_t block, unsigned size)
> +{
> + return find_get_block_common(bdev, block, size, true);
> +}
> EXPORT_SYMBOL(__find_get_block);
>
> /**
> --
> 2.39.5
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2025-04-16 9:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 23:16 [PATCH -next 0/7] fs/buffer: split pagecache lookups into atomic or blocking Davidlohr Bueso
2025-04-15 23:16 ` [PATCH 1/7] fs/buffer: split locking for pagecache lookups Davidlohr Bueso
2025-04-16 9:32 ` Jan Kara [this message]
2025-04-15 23:16 ` [PATCH 2/7] fs/buffer: introduce sleeping flavors " Davidlohr Bueso
2025-04-16 9:33 ` Jan Kara
2025-04-15 23:16 ` [PATCH 3/7] fs/buffer: use sleeping version of __find_get_block() Davidlohr Bueso
2025-04-16 9:33 ` Jan Kara
2025-04-15 23:16 ` [PATCH 4/7] fs/ocfs2: " Davidlohr Bueso
2025-04-16 9:35 ` Jan Kara
2025-04-15 23:16 ` [PATCH 5/7] fs/jbd2: " Davidlohr Bueso
2025-04-16 9:38 ` Jan Kara
2025-04-15 23:16 ` [PATCH 6/7] fs/ext4: use sleeping version of sb_find_get_block() Davidlohr Bueso
2025-04-16 9:39 ` Jan Kara
2025-04-15 23:16 ` [PATCH 7/7] mm/migrate: fix sleep in atomic for large folios and buffer heads Davidlohr Bueso
2025-04-16 9:43 ` Jan Kara
2025-04-16 19:27 ` [PATCH -next 0/7] fs/buffer: split pagecache lookups into atomic or blocking Luis Chamberlain
2025-04-17 9:57 ` Christian Brauner
2025-04-22 11:25 ` Jan Kara
2025-04-17 9:58 ` Christian Brauner
2025-04-18 1:59 [PATCH v2 " Davidlohr Bueso
2025-04-18 1:59 ` [PATCH 1/7] fs/buffer: split locking for pagecache lookups Davidlohr Bueso
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=bu3ppl5dpe4kf5ykx4mkkg3vccsqkie335oa7wywv6eyvbp2fk@f4yyphvoczty \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=brauner@kernel.org \
--cc=dave@stgolabs.net \
--cc=djwong@kernel.org \
--cc=hare@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=tytso@mit.edu \
--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