On Fri, 26 Jul 2024 at 12:21, Lorenzo Stoakes
<lorenzo.stoakes@oracle.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