linux-kernel - Re: [GIT PULL] bitmap patches for v6.8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh02qG1CtiQ-pPDcpbiZUx6AEdfAYPbp0nJ7wyzdHmEkw@mail.gmail.com>
Date: Sun, 21 Jan 2024 13:47:21 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yury Norov <yury.norov@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Alexandra Winter <wintera@...ux.ibm.com>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Bart Van Assche <bvanassche@....org>, 
	Bjorn Helgaas <bhelgaas@...gle.com>, Chengming Zhou <zhouchengming@...edance.com>, 
	Dave Jiang <dave.jiang@...el.com>, Edward Cree <ecree.xilinx@...il.com>, 
	Fenghua Yu <fenghua.yu@...el.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, 
	Greg Ungerer <gerg@...ux-m68k.org>, Guanjun <guanjun@...ux.alibaba.com>, 
	Hans Verkuil <hverkuil-cisco@...all.nl>, Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>, 
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Michael Kelley <mhklinux@...look.com>, 
	Oliver Neukum <oneukum@...e.com>, Peter Zijlstra <peterz@...radead.org>, 
	Rasmus Villemoes <linux@...musvillemoes.dk>, Sean Christopherson <seanjc@...gle.com>, 
	Takashi Iwai <tiwai@...e.de>, Tony Lu <tonylu@...ux.alibaba.com>, Vinod Koul <vkoul@...nel.org>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>, Wei Liu <wei.liu@...nel.org>, 
	Wen Gu <guwen@...ux.alibaba.com>, Will Deacon <will@...nel.org>
Subject: Re: [GIT PULL] bitmap patches for v6.8

So I've left this to be my last pull request, because I hate how our
header files are growing, and this part:

 include/linux/find.h | 301 ++++++++++++++++++++++++++++++-
 1 file changed, 297 insertions(+), 4 deletions(-)

in particular.

Nobody includes <linux/find.h> directly, but indirectly pretty much
*every* single kernel C file includes it.

Looking at some basic stats of my dependency files in my tree, 4426 of
4526 object files (~98%) depend on find.h because they get it through
*some* path that ends up with bitmap.h -> find.h.

And honestly, the number of files that actually want the new functions
is basically just a tiny handful. It's also not obvious how useful
those optimizations are, considering that a lot of the loops are
*tiny*. I looked at a few cases, and the size of the bitmap it was
iterating over was often in the 2-4 range, sometimes (like
RTW89_TXCH_NUM) 13, etc.

In radio-shark, you replaced a loop like this

        for (i = 0; i < 2; i++) {

with that for_each_test_and_clear_bit(), and it *really* isn't clear
that it was worth it. It sure wasn't performance-critical to begin
with.

In general, if an "optimization" doesn't have any performance numbers
attached to it, is it an optimization at all?

So I finally ended up pulling this, but after looking at the patch I
went "this is adding more lines than it removes, has no performance
numbers, and grows a core header file that is included by absolutely
everything by a third".

. and then I decided to just unpull it again.

                  Linus