Linux block layer
 help / color / mirror / Atom feed
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"?

  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