[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d62cd2d-a00b-4260-8ffb-0e0e4574f222@lucifer.local>
Date: Wed, 24 Jul 2024 09:31:27 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jürgen Groß <jgross@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, david.laight@...lab.com,
Arnd Bergmann <arnd@...nel.org>, willy@...radead.org,
torvalds@...ux-foundation.org, Jason@...c4.com, hch@...radead.org,
andriy.shevchenko@...ux.intel.com, pedro.falcato@...il.com,
Mateusz Guzik <mjguzik@...il.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: Build performance regressions originating from min()/max() macros
On Wed, Jul 24, 2024 at 10:14:12AM GMT, Jürgen Groß wrote:
> On 23.07.24 23:59, Lorenzo Stoakes wrote:
> > Arnd reported a significant build slowdown [0], which was bisected to the
> > series spanning commit 80fcac55385c ("minmax: relax check to allow
> > comparison between unsigned arguments and signed constants") to commit
> > 867046cc70277 ("minmax: relax check to allow comparison between unsigned
> > arguments and signed constants"), originating from the series "minmax:
> > Relax type checks in min() and max()." [1].
[snip]
> I can send a patch to simplify the problematic construct, but OTOH this
> will avoid only one particularly bad example.
Thanks, appreciated but I am a little concerned that we might get stuck in
whack-a-mole here a bit. I'm pretty sure we've had previous patches that
have addressed invocation points, but obviously the underlying issue are
these macros which will keep cropping up again and again.
>
>
> Juergen
Powered by blists - more mailing lists