Re: Build performance regressions originating from min()/max() macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24.07.24 10:31, Lorenzo Stoakes wrote:
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.

The xen example seems to be one of the worst due to nesting of min3() and
min(), so being de facto a min4().

I think drivers/firmware/sysfb_simplefb.c has a similar problem, as it is
nesting max() with max3(). Same applies to arch/x86/kernel/cpu/cacheinfo.c
and multiple times to fs/xfs/libxfs/xfs_trans_resv.c.

There are probably more such extreme cases.


Juergen




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux