[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <969b864a-a27a-4bdc-ae1e-e6132dfbfca4@lucifer.local>
Date: Sat, 27 Jul 2024 17:41:31 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>,
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 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
>
Powered by blists - more mailing lists