public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	willy@infradead.org, axboe@kernel.dk
Subject: Re: [PATCH 0/2] bio iter improvements
Date: Mon, 3 Apr 2023 12:36:20 -0400	[thread overview]
Message-ID: <ZCsAhDpsiNWpiAxS@moria.home.lan> (raw)
In-Reply-To: <ZCrsbv+zKGf4jvUm@infradead.org>

On Mon, Apr 03, 2023 at 08:10:38AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 28, 2023 at 04:28:08PM -0400, Kent Overstreet wrote:
> > > Can you post a code size comparism for the before and after cases?
> > 
> > 6.2:
> > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux
> >    text    data     bss     dec     hex filename
> > 13234215        5355074  872448 19461737        128f669 ktest-out/kernel_build.x86_64/vmlinux
> > 
> > With patches:
> > kent@moria:~/linux$ size ktest-out/kernel_build.x86_64/vmlinux
> >    text    data     bss     dec     hex filename
> > 13234215        5355578  872448 19462241        128f861 ktest-out/kernel_build.x86_64/vmlinux
> 
> So we have a slightly larger binary size, and a slighly larger source
> code size.  What is the overall benefit of this conversion?

Data went up a bit because I added some asserts, yes. And it's also not
uncommon for source code to grow a bit when you start focusing on
readability instead of just playing code golf.

And that was one of the main motivations - Matthew was complaining about
the bio iter code being a pain in the ass when he did the bio folio iter
code; additionally, I realized I could do a much cleaner and smaller
version of bio_for_each_folio() with some refactoring of the existing
code.

But this was all right there in the original commit message. And to be
honest Christoph, these kinds of drive by "let's focus on the easiest
thing to measure" comments are what I expect from you at this point, but
I don't find them to be super helpful. Reads like a typical MBA manager
who just wants to focus on making their silly charts going up, instead
of digging in and understanding what's going on. Was it your time in
FinTech that you got that from...?

If we want object size to go back down, we could
 - convert WARN_ONS() to BUG_ON()s (Linus won't like that)
 - drop the new assertions (_I_ wouldn't like that)
 - switch from inlines to out-of-line functions - this'll make text size
   go down vs. baseline, but if there's a performance impact Jens will
   care about that.

Anyways, I've got a patch converting to out-of-line functions but I
don't have as sensitive a performance testing setup as Jens does. If the
patch is interesting to people - if Jens wants to perf test it or just
take it - I'm happy to post it too.

  reply	other threads:[~2023-04-03 16:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 17:44 [PATCH 0/2] bio iter improvements Kent Overstreet
2023-03-27 17:44 ` [PATCH 1/2] block: Rework bio_for_each_segment_all() Kent Overstreet
2023-03-29 16:50   ` Phillip Lougher
2023-03-30 17:55     ` Kent Overstreet
2023-03-30 18:59       ` Phillip Lougher
2023-03-31  1:10         ` Phillip Lougher
2023-04-01  2:28           ` Kent Overstreet
2023-04-03 13:57             ` Phillip Lougher
2023-03-30 11:49   ` Ming Lei
2023-03-30 16:20     ` Kent Overstreet
2023-03-27 17:44 ` [PATCH 2/2] block: Rework bio_for_each_folio_all() Kent Overstreet
2023-04-03 15:13   ` Christoph Hellwig
2023-04-03 15:51     ` Kent Overstreet
2023-03-27 22:14 ` [PATCH 0/2] bio iter improvements Christoph Hellwig
2023-03-28 20:28   ` Kent Overstreet
2023-04-03 15:10     ` Christoph Hellwig
2023-04-03 16:36       ` Kent Overstreet [this message]
2023-04-04 15:20         ` Christoph Hellwig
2023-04-04 15:47           ` Kent Overstreet
2023-04-04 15:59             ` Christoph Hellwig
2023-04-04 16:08               ` Kent Overstreet
2023-04-04 16:01             ` Jens Axboe
2023-04-04 16:06               ` Kent Overstreet
2023-04-04 16:14                 ` Jens Axboe
2023-04-04 17:11                   ` Kent Overstreet
2023-03-28 13:42 ` Phillip Lougher
2023-03-28 16:57   ` Kent Overstreet
2023-03-29 16:41     ` Phillip Lougher

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=ZCsAhDpsiNWpiAxS@moria.home.lan \
    --to=kent.overstreet@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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