[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjv-DkukaKb7f04WezyPjRERp=xfxv34j5fA8cDQ_JudA@mail.gmail.com>
Date: Thu, 20 Jun 2024 12:26:18 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yury Norov <yury.norov@...il.com>
Cc: linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
"H. Peter Anvin" <hpa@...or.com>, "James E.J. Bottomley" <jejb@...ux.ibm.com>,
"K. Y. Srinivasan" <kys@...rosoft.com>, "Md. Haris Iqbal" <haris.iqbal@...os.com>,
Akinobu Mita <akinobu.mita@...il.com>, Andrew Morton <akpm@...ux-foundation.org>,
Bjorn Andersson <andersson@...nel.org>, Borislav Petkov <bp@...en8.de>, Chaitanya Kulkarni <kch@...dia.com>,
Christian Brauner <brauner@...nel.org>, Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, David Disseldorp <ddiss@...e.de>,
Edward Cree <ecree.xilinx@...il.com>, Eric Dumazet <edumazet@...gle.com>,
Fenghua Yu <fenghua.yu@...el.com>, Geert Uytterhoeven <geert@...ux-m68k.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Gregory Greenman <gregory.greenman@...el.com>,
Hans Verkuil <hverkuil@...all.nl>, Hans de Goede <hdegoede@...hat.com>,
Hugh Dickins <hughd@...gle.com>, Ingo Molnar <mingo@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>, Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>,
Jiri Pirko <jiri@...nulli.us>, Jiri Slaby <jirislaby@...nel.org>, Kalle Valo <kvalo@...nel.org>,
Karsten Graul <kgraul@...ux.ibm.com>, Karsten Keil <isdn@...ux-pingi.de>,
Kees Cook <keescook@...omium.org>, Leon Romanovsky <leon@...nel.org>,
Mark Rutland <mark.rutland@....com>, Martin Habets <habetsm.xilinx@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Michael Ellerman <mpe@...erman.id.au>, Michal Simek <monstr@...str.eu>,
Nicholas Piggin <npiggin@...il.com>, Oliver Neukum <oneukum@...e.com>, Paolo Abeni <pabeni@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Ping-Ke Shih <pkshih@...ltek.com>, Rich Felker <dalias@...c.org>, Rob Herring <robh@...nel.org>,
Robin Murphy <robin.murphy@....com>, Sean Christopherson <seanjc@...gle.com>,
Shuai Xue <xueshuai@...ux.alibaba.com>, Stanislaw Gruszka <stf_xl@...pl>,
Steven Rostedt <rostedt@...dmis.org>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Thomas Gleixner <tglx@...utronix.de>, Valentin Schneider <vschneid@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>, Wenjia Zhang <wenjia@...ux.ibm.com>,
Will Deacon <will@...nel.org>, Yoshinori Sato <ysato@...rs.sourceforge.jp>,
GR-QLogic-Storage-Upstream@...vell.com, alsa-devel@...a-project.org,
ath10k@...ts.infradead.org, dmaengine@...r.kernel.org, iommu@...ts.linux.dev,
kvm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-block@...r.kernel.org,
linux-bluetooth@...r.kernel.org, linux-hyperv@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, linux-media@...r.kernel.org,
linux-mips@...r.kernel.org, linux-net-drivers@....com,
linux-pci@...r.kernel.org, linux-rdma@...r.kernel.org,
linux-s390@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-serial@...r.kernel.org, linux-sh@...r.kernel.org,
linux-sound@...r.kernel.org, linux-usb@...r.kernel.org,
linux-wireless@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
mpi3mr-linuxdrv.pdl@...adcom.com, netdev@...r.kernel.org,
sparclinux@...r.kernel.org, x86@...nel.org,
Alexey Klimov <alexey.klimov@...aro.org>, Bart Van Assche <bvanassche@....org>, Jan Kara <jack@...e.cz>,
Matthew Wilcox <willy@...radead.org>, Mirsad Todorovac <mirsad.todorovac@....unizg.hr>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Sergey Shtylyov <s.shtylyov@....ru>
Subject: Re: [PATCH v4 00/40] lib/find: add atomic find_bit() primitives
On Thu, 20 Jun 2024 at 11:32, Yury Norov <yury.norov@...il.com> wrote:
>
> Is that in master already? I didn't get any email, and I can't find
> anything related in the master branch.
It's 5d272dd1b343 ("cpumask: limit FORCE_NR_CPUS to just the UP case").
> > New rule: before you send some optimization, you need to have NUMBERS.
>
> I tried to underline that it's not a performance optimization at my
> best.
If it's not about performance, then it damn well shouldn't be 90%
inline functions in a header file.
If it's a helper function, it needs to be a real function elsewhere. Not this:
include/linux/find_atomic.h | 324 +++++++++++++++++++
because either performance really matters, in which case you need to
show profiles, or performance doesn't matter, in which case it damn
well shouldn't have special cases for small bitsets that double the
size of the code.
Linus
Powered by blists - more mailing lists