linux-kernel - Re: [PATCH 0/7] minmax: reduce compilation time

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: <CAHk-=wjPr3b-=dshE6n3fM2Q0U3guT4reOoCZiBye_UMJ-qg1A@mail.gmail.com>
Date: Fri, 26 Jul 2024 14:36:40 -0700
From: Linus Torvalds <torvalds@...uxfoundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Jens Axboe <axboe@...nel.dk>
Cc: David Laight <David.Laight@...lab.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"Matthew Wilcox (Oracle)" <willy@...radead.org>, Christoph Hellwig <hch@...radead.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Dan Carpenter <dan.carpenter@...aro.org>, Arnd Bergmann <arnd@...nel.org>, 
	"Jason@...c4.com" <Jason@...c4.com>, "pedro.falcato@...il.com" <pedro.falcato@...il.com>, 
	Mateusz Guzik <mjguzik@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/7] minmax: reduce compilation time

On Fri, 26 Jul 2024 at 12:21, Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> A simple comparison pre-revert vs. post-revert gives some ideas for other
> low-hanging fruit:
>
>   1334256./mm/compaction.o.pre

LOL. At least some of that is because of 'pageblock_order', which
expands to 2.5kB of text just because of this:

  /*
   * Huge pages are a constant size, but don't exceed the maximum allocation
   * granularity.
   */
  #define pageblock_order    min_t(unsigned int, HUGETLB_PAGE_ORDER,
MAX_PAGE_ORDER)

I think the two arguments to "min_t" are literally "(21 - 12)" and
"10", and it expands to 2.5kB.

So it _looks_ like "pageblock_order", and it *acts* like a simple
compile-time constant, but our complex type-checking min() macro ends
up making it horrible.

But no, that's not nearly the longest expansion. Writing a little
script, and I get

   Longest line is 85061 (253kB)

so we have a single expansion that is 253kB in size. And it comes from this:

                case ISOLATE_SUCCESS:
                        update_cached = false;
                        last_migrated_pfn = max(cc->zone->zone_start_pfn,
                                pageblock_start_pfn(cc->migrate_pfn - 1));

where that "max()" ends up interacting with "pageblock_start_pfn()",
and that pageblock_start_pfn() thing is

  #define pageblock_nr_pages      (1UL << pageblock_order)
  #define pageblock_start_pfn(pfn)  ALIGN_DOWN((pfn), pageblock_nr_pages)

so once again it's "pageblock_order", it's just that it's now mixed in
with "max()".

Now, fixing that, and you end up with

  Longest line is 61861 (82kB)

so it's now "only" 82kB in size, and that actually comes from
<linux/bio.h>, which has this:

   static inline unsigned bio_segments(struct bio *bio)
   {
   ...
        bio_for_each_segment(bv, bio, iter)
                segs++;

which looks very tame indeed, but it turns out that
"bio_for_each_segment()" expands to 82kB of code.

Jens? Maybe time to look into this?

               Linus

View attachment "patch.diff" of type "text/x-patch" (2379 bytes)

View attachment "longest-line.c" of type "text/x-csrc" (1046 bytes)