From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB98CC48BE5 for ; Sat, 19 Jun 2021 16:24:21 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8D29061222 for ; Sat, 19 Jun 2021 16:24:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D29061222 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 000906EB38; Sat, 19 Jun 2021 16:24:20 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5D4AB6EB38; Sat, 19 Jun 2021 16:24:18 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5BE6761208; Sat, 19 Jun 2021 16:24:18 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ludlY-008chF-A9; Sat, 19 Jun 2021 17:24:16 +0100 Date: Sat, 19 Jun 2021 17:24:15 +0100 Message-ID: <87bl81ddqo.wl-maz@kernel.org> From: Marc Zyngier To: Yury Norov Subject: Re: [PATCH 2/3] find: micro-optimize for_each_{set,clear}_bit() In-Reply-To: <20210618195735.55933-3-yury.norov@gmail.com> References: <20210618195735.55933-1-yury.norov@gmail.com> <20210618195735.55933-3-yury.norov@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: yury.norov@gmail.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, l.stach@pengutronix.de, linux+etnaviv@armlinux.org.uk, christian.gmeiner@gmail.com, airlied@linux.ie, daniel@ffwll.ch, jdelvare@suse.com, linux@roeck-us.net, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, dwmw@amazon.co.uk, akpm@linux-foundation.org, richard.weiyang@linux.alibaba.com, geert+renesas@glider.be, aklimov@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-hwmon@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wei Yang , Geert Uytterhoeven , David Airlie , Rasmus Villemoes , dri-devel@lists.freedesktop.org, "H. Peter Anvin" , x86@kernel.org, Ingo Molnar , Russell King , Guenter Roeck , Jean Delvare , Alexey Klimov , etnaviv@lists.freedesktop.org, Borislav Petkov , Thomas Gleixner , Andy Shevchenko , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , David Woodhouse Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 18 Jun 2021 20:57:34 +0100, Yury Norov wrote: > > The macros iterate thru all set/clear bits in a bitmap. They search a > first bit using find_first_bit(), and the rest bits using find_next_bit(). > > Since find_next_bit() is called shortly after find_first_bit(), we can > save few lines of I-cache by not using find_first_bit(). Really? > > Signed-off-by: Yury Norov > --- > include/linux/find.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/find.h b/include/linux/find.h > index 4500e8ab93e2..ae9ed52b52b8 100644 > --- a/include/linux/find.h > +++ b/include/linux/find.h > @@ -280,7 +280,7 @@ unsigned long find_next_bit_le(const void *addr, unsigned > #endif > > #define for_each_set_bit(bit, addr, size) \ > - for ((bit) = find_first_bit((addr), (size)); \ > + for ((bit) = find_next_bit((addr), (size), 0); \ On which architecture do you observe a gain? Only 32bit ARM and m68k implement their own version of find_first_bit(), and everyone else uses the canonical implementation: #ifndef find_first_bit #define find_first_bit(addr, size) find_next_bit((addr), (size), 0) #endif These architectures explicitly have different implementations for find_first_bit() and find_next_bit() because they can do better (whether that is true or not is another debate). I don't think you should remove this optimisation until it has been measured on these two architectures. Thanks, M. -- Without deviation from the norm, progress is not possible.