linux-kernel - Re: [PATCH 0/2] bio iter improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZCsAhDpsiNWpiAxS@moria.home.lan>
Date:   Mon, 3 Apr 2023 12:36:20 -0400
From:   Kent Overstreet <kent.overstreet@...ux.dev>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        willy@...radead.org, axboe@...nel.dk
Subject: Re: [PATCH 0/2] bio iter improvements

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@...ia:~/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@...ia:~/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.