Received-SPF: pass (google.com: domain of linux-kernel+bounces-32194-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <ZZwrbDUe4VQRYv5I@yury-ThinkPad>
In-Reply-To: <ZZwrbDUe4VQRYv5I@yury-ThinkPad>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 21 Jan 2024 13:47:21 -0800
Message-ID: <CAHk-=wh02qG1CtiQ-pPDcpbiZUx6AEdfAYPbp0nJ7wyzdHmEkw@mail.gmail.com>
Subject: Re: [GIT PULL] bitmap patches for v6.8
To: Yury Norov <yury.norov@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Alexandra Winter <wintera@linux.ibm.com>, 
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Bart Van Assche <bvanassche@acm.org>, 
	Bjorn Helgaas <bhelgaas@google.com>, Chengming Zhou <zhouchengming@bytedance.com>, 
	Dave Jiang <dave.jiang@intel.com>, Edward Cree <ecree.xilinx@gmail.com>, 
	Fenghua Yu <fenghua.yu@intel.com>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Greg Ungerer <gerg@linux-m68k.org>, Guanjun <guanjun@linux.alibaba.com>, 
	Hans Verkuil <hverkuil-cisco@xs4all.nl>, Jan Kara <jack@suse.cz>, Jens Axboe <axboe@kernel.dk>, 
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, 
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Michael Kelley <mhklinux@outlook.com>, 
	Oliver Neukum <oneukum@suse.com>, Peter Zijlstra <peterz@infradead.org>, 
	Rasmus Villemoes <linux@rasmusvillemoes.dk>, Sean Christopherson <seanjc@google.com>, 
	Takashi Iwai <tiwai@suse.de>, Tony Lu <tonylu@linux.alibaba.com>, Vinod Koul <vkoul@kernel.org>, 
	Vitaly Kuznetsov <vkuznets@redhat.com>, Wei Liu <wei.liu@kernel.org>, 
	Wen Gu <guwen@linux.alibaba.com>, Will Deacon <will@kernel.org>
Content-Type: text/plain; charset="UTF-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