From: Pavel Begunkov <asml.silence@gmail.com>
To: Fengnan Chang <changfengnan@bytedance.com>,
Christoph Hellwig <hch@infradead.org>
Cc: fengnan chang <fengnanchang@gmail.com>,
axboe@kernel.dk, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, willy@infradead.org, djwong@kernel.org,
ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org, linux-xfs@vger.kernel.org,
linux-ext4@vger.kernel.org
Subject: Re: [External] Re: [PATCH] block: enable per-cpu bio cache by default
Date: Mon, 13 Oct 2025 14:31:32 +0100 [thread overview]
Message-ID: <d785cc8e-d8fd-4bee-950c-7f3f7d452efc@gmail.com> (raw)
In-Reply-To: <CAPFOzZumoCERUj+VuegQNoAwFCoGxiaASD6R_4bE+p1TVbspUA@mail.gmail.com>
On 10/13/25 13:58, Fengnan Chang wrote:
> Christoph Hellwig <hch@infradead.org> 于2025年10月13日周一 14:28写道:
>>
>> On Mon, Oct 13, 2025 at 01:42:47PM +0800, fengnan chang wrote:
>>>> Just set the req flag in the branch instead of unconditionally setting
>>>> it and then clearing it.
>>>
>>> clearing this flag is necessary, because bio_alloc_clone will call this in
>>> boot stage, maybe the bs->cache of the new bio is not initialized yet.
>>
>> Given that we're using the flag by default and setting it here,
>> bio_alloc_clone should not inherit it. In fact we should probably
>> figure out a way to remove it entirely, but if that is not possible
>> it should only be set when the cache was actually used.
>
> For now bio_alloc_clone will inherit all flag of source bio, IMO if only not
> inherit REQ_ALLOC_CACHE, it's a little strange.
> The REQ_ALLOC_CACHE flag can not remove entirely. maybe we can
> modify like this:
>
> if (bs->cache && nr_vecs <= BIO_INLINE_VECS) {
> opf |= REQ_ALLOC_CACHE;
> bio = bio_alloc_percpu_cache(bdev, nr_vecs, opf,
> gfp_mask, bs);
> if (bio)
> return bio;
> /*
> * No cached bio available, bio returned below marked with
> * REQ_ALLOC_CACHE to participate in per-cpu alloc cache.
> */
> } else
> opf &= ~REQ_ALLOC_CACHE;
>
>>
>>>>> + /*
>>>>> + * Even REQ_ALLOC_CACHE is enabled by default, we still need this to
>>>>> + * mark bio is allocated by bio_alloc_bioset.
>>>>> + */
>>>>> if (rq->cmd_flags & REQ_ALLOC_CACHE && (nr_vecs <= BIO_INLINE_VECS)) {
>>>>
>>>> I can't really parse the comment, can you explain what you mean?
>>>
>>> This is to tell others that REQ_ALLOC_CACHE can't be deleted here, and
>>> that this flag
>>> serves other purposes here.
>>
>> So what can't it be deleted?
>
> blk_rq_map_bio_alloc use REQ_ALLOC_CACHE to tell whether to use
> bio_alloc_bioset or bio_kmalloc, I considered removing the flag in
> blk_rq_map_bio_alloc, but then there would have to be the introduction
> of a new flag like REQ_xx. So I keep this and comment.
That can likely be made unconditional as well. Regardless of that,
it can't be removed without additional changes because it's used to
avoid de-allocating into the pcpu cache requests that wasn't
allocated for it. i.e.
if (bio->bi_opf & REQ_ALLOC_CACHE)
bio_put_percpu_cache(bio);
else
bio_free(bio);
Without it under memory pressure you can end up in a situation
where bios are put into pcpu caches of other CPUs and can't be
reallocated by the current CPU, effectively loosing the mempool
forward progress guarantees. See:
commit 759aa12f19155fe4e4fb4740450b4aa4233b7d9f
Author: Pavel Begunkov <asml.silence@gmail.com>
Date: Wed Nov 2 15:18:20 2022 +0000
bio: don't rob starving biosets of bios
--
Pavel Begunkov
next prev parent reply other threads:[~2025-10-13 13:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 1:33 [PATCH] block: enable per-cpu bio cache by default Fengnan Chang
2025-10-11 1:36 ` fengnan chang
2025-10-11 1:43 ` fengnan chang
2025-10-13 3:24 ` Christoph Hellwig
2025-10-13 5:42 ` fengnan chang
2025-10-13 6:28 ` Christoph Hellwig
2025-10-13 12:58 ` [External] " Fengnan Chang
2025-10-13 13:31 ` Pavel Begunkov [this message]
2025-10-14 2:38 ` Fengnan Chang
2025-10-13 5:18 ` Ming Lei
2025-10-13 5:44 ` fengnan chang
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=d785cc8e-d8fd-4bee-950c-7f3f7d452efc@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=changfengnan@bytedance.com \
--cc=djwong@kernel.org \
--cc=fengnanchang@gmail.com \
--cc=hch@infradead.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--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;
as well as URLs for NNTP newsgroup(s).