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

Lorenzo Stoakes
2024-07-27T16:43:21Z

On Sat, Jul 27, 2024 at 10:36:30AM GMT, Jens Axboe wrote:
> On 7/27/24 10:31 AM, Lorenzo Stoakes wrote:
[snip]
> > I tried this patch, doesn't seem to make a huge difference, going from
> > 3,958,564 bytes with longest line of 82 kB to 3,943,824 bytes with a
> > longest line of 77kB.
> >
> > It seems that the .bv_len = ... expansion is what's doing it, so I tried
> > patching mp_bvec_iter_len() as well to do a silly ?: thing (sorry), which
> > takes us down to 3,880,309 with longest line of 20kB.
>
> Right, I did compile it after the fact and applied the same thing to
> mp_bvec_iter_len().

Ah cool :)

>
> > This is starting to feel like whack-a-mole isn't it? I looked at the next
> > longest line, which originates from include/linux/pid_namespace.h believe
> > it or not where some compiler cleverness + a loop is resulting in _another_
> > combinatorial explosion.
>
> Oh it's certainly whack-a-mole, doesn't mean it's not worth doing for
> the low hanging stuff :-)

Yeah I'd say getting down to 20 or 16kB is probably worth it, hardly
difficult.

I guess I resent the fact we're being forced to do this because of insanity
in the macros.. but if it's obvious and not going to cause regressions in
existing code then no harm.

>
> > Patch attached including Jens's change + mine.
>
> bvec side matches what I have here, fwiw, except I also did
> mp_bvec_iter_len(). Didn't see big expansion there, but might as well
> keep them consistent.

Makes sense, am happy to give R-b tag for this patch if you want to put it
forward? Not sure if Linus is minded to just pull something for this now?

If we're whack-a-moleing may as well sort the drivers I found in my
allmodconfig too obviously as some hilariously low-hanging fruit there...

>
> --
> Jens Axboe
>