From: Christoph Hellwig <hch@infradead.org>
To: Steven Feng <steven@joint-cloud.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: optimize I/O merge hot path with unlikely() hints
Date: Tue, 9 Jun 2026 00:38:47 -0700 [thread overview]
Message-ID: <aifDBykDgb59AIRh@infradead.org> (raw)
In-Reply-To: <tencent_79B652BD0CC23E093F27914380F161E7E505@qq.com>
On Sat, Jun 06, 2026 at 10:42:18AM +0800, Steven Feng wrote:
> Remove redundant '== false' comparisons and add unlikely() branch
> prediction hints in block I/O merge path functions.
>
> These functions (ll_new_hw_segment, ll_merge_requests_fn, and
> blk_rq_merge_ok) are executed on every I/O request merge attempt,
> making them critical hot paths. Data integrity check failures are
> rare events, so marking these conditions as unlikely() helps the
> CPU optimize the common case by improving branch prediction.
Umm, these are not failures. Just conditions to not merge because
of this, and not merging, both because of these conditions and others,
it the most common case for most workloads.
With your patch the object file size of blk-merge.o increases slightly
for me on x86_64:
text data bss dec hex filename
12299 577 0 12876 324c block/blk-merge.o.old
12331 577 0 12908 326c block/blk-merge.o
and looking at the assembly this is due to worse code generation
because it now splits different error returns.
What kind of optimization are you attempting and how did you measure
the results of this "optimizatіon"?
next prev parent reply other threads:[~2026-06-09 7:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 2:42 [PATCH] block: optimize I/O merge hot path with unlikely() hints Steven Feng
2026-06-08 14:34 ` Jens Axboe
2026-06-09 7:38 ` Christoph Hellwig [this message]
[not found] <20260606024218.12345-1-steven@joint-cloud.com>
[not found] ` <ZmUjB3aF8K1xYzHr@lst.de>
2026-06-09 8:24 ` Steven Feng
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=aifDBykDgb59AIRh@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=steven@joint-cloud.com \
/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