From patchwork Thu Feb 25 13:56:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yury Norov X-Patchwork-Id: 12104161 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=-13.7 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 817D5C433E0 for ; Thu, 25 Feb 2021 13:58:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 2434F64F03 for ; Thu, 25 Feb 2021 13:58:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2434F64F03 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uUAB7MYPj8paB2uGQ+MdUpYEMoe+vAuk+AYtXkCUDgs=; b=DyW7f5yggIzs068/Sqho01Vsh PGfYyavIjfige/JLJXwEJ0xPCFOYyqGVOo94QdQWng2KYLyp1d1jNq+XhXwbX3yg6ELnGKwZ2uxc9 6jGgleGp7rw135Hq/z//ifAjqDSNSDjvyKM4weRTdFiMLIhvy+HAxC++7W6+CNxs7P+0ozlxVntfF b+sDy9d6mr3CEFcbWxq2h7DLKepsuc7QZelrAaPRlWic0gpWqlJOD84G5nXUFTjBPVXgc94DNxltA EnTgdqkt1zTnPNol7lBiSUkFeYpVCC26UXWm1Nx+2CxobW1HQnX96b6vrVAaORGRNMuXJwApuFQpt 9F7uVAhiw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFH8o-0005Gz-0S; Thu, 25 Feb 2021 13:57:18 +0000 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lFH8e-0005Ez-MX for linux-arm-kernel@lists.infradead.org; Thu, 25 Feb 2021 13:57:09 +0000 Received: by mail-qt1-x82b.google.com with SMTP id v3so4095227qtw.4 for ; Thu, 25 Feb 2021 05:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=B+Er2AMgvvg9wNih89ONA7/yh52BeqTQADmg6hQCNNk=; b=oANFhxvwcRf+H93mDQVdIHtrafrmXMO69qpuNH5wFtBiIk65oCljFf3wn0j9jWD8Jf xn773fkXJ5cBecoo8uOiGVpVCd00OKIG+d/kDiqhzaL2TAP9FyYPMdmUPtcF+ogzFkPL es0Tc7y/WEes/sMCApl5bUip4fDutrrP3R0PZJ4JgJ00N+RMCEqK+DNA9AdpAnhPfl+w dVIhFJFqSCTCZEepp/T3/mXx1z5U3ubcmCMBf6t5yJxmvT7cZUHy6rjLdJh6/PzYLgG9 yFiuCDoMYIdVI33U7YCIGPueqX1+1YpI0ifvCK5aWl7TbDuBok5CUIQ0bNVadRTvBEgI bgMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=B+Er2AMgvvg9wNih89ONA7/yh52BeqTQADmg6hQCNNk=; b=cqXkmFwN1OK4RCiC6vnqNDW1iCclEB2CszDtlMy/blX4+hNp1wI6W/8MGrFeuNufy6 HCDtOunP8pJgnx0DnlYEqZZ1mi0E02UwK/c4SbLBldVVGaEr0Rb72FAzcreFPJ0YO+1N mEg1rvJqhUgkjp3AKT/n7C0KT7YodIqvizNzrJAiu7pwGxZNH+/Ow2XiCM/Qx8wuf+OG L0uaYSyEASClpOZ6UiMOS10w7isOFAjwz0noJakGqqv4gQumind6QsYY6TnPGia8BjVE TjC5EBCf6O+cnKH3CRvuJbAM04/oDtEebn1PpzDi/S9K/rH3xuhkOY1edqKhi64kvKyo 7m8w== X-Gm-Message-State: AOAM532HlZPNm04yJKYGF8T5vHOvWLYPlAnvttXU41y51Gif96XggIqZ VKr8lEUKB6y3y7aCTwWsrR4bVOVPWBs= X-Google-Smtp-Source: ABdhPJx245qzXjqscdkfz2xTv/fJGcyhYJpB7sYfuTawFg2dSpSKA/6rKwLo4Qv96QoYYrlnwcVfbw== X-Received: by 2002:ac8:6958:: with SMTP id n24mr2377747qtr.110.1614261425391; Thu, 25 Feb 2021 05:57:05 -0800 (PST) Received: from localhost (d27-96-190-162.evv.wideopenwest.com. [96.27.162.190]) by smtp.gmail.com with ESMTPSA id f17sm3514072qtv.93.2021.02.25.05.57.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 05:57:05 -0800 (PST) From: Yury Norov To: Will Deacon , Catalin Marinas , Thomas Bogendoerfer , Alexander Lobakin , Alexey Klimov , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mips@vger.kernel.org Subject: [RESEND PATCH 1/2] ARM64: enable GENERIC_FIND_FIRST_BIT Date: Thu, 25 Feb 2021 05:56:59 -0800 Message-Id: <20210225135700.1381396-2-yury.norov@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210225135700.1381396-1-yury.norov@gmail.com> References: <20210225135700.1381396-1-yury.norov@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210225_085708_766906_52B4900E X-CRM114-Status: GOOD ( 13.33 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Yury Norov Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't enable it in a config. It leads to using find_next_bit() which is less efficient: 0000000000000000 : 0: aa0003e4 mov x4, x0 4: aa0103e0 mov x0, x1 8: b4000181 cbz x1, 38 c: f9400083 ldr x3, [x4] 10: d2800802 mov x2, #0x40 // #64 14: 91002084 add x4, x4, #0x8 18: b40000c3 cbz x3, 30 1c: 14000008 b 3c 20: f8408483 ldr x3, [x4], #8 24: 91010045 add x5, x2, #0x40 28: b50000c3 cbnz x3, 40 2c: aa0503e2 mov x2, x5 30: eb02001f cmp x0, x2 34: 54ffff68 b.hi 20 // b.pmore 38: d65f03c0 ret 3c: d2800002 mov x2, #0x0 // #0 40: dac00063 rbit x3, x3 44: dac01063 clz x3, x3 48: 8b020062 add x2, x3, x2 4c: eb02001f cmp x0, x2 50: 9a829000 csel x0, x0, x2, ls // ls = plast 54: d65f03c0 ret ... 0000000000000118 <_find_next_bit.constprop.1>: 118: eb02007f cmp x3, x2 11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast 120: d346fc66 lsr x6, x3, #6 124: f8667805 ldr x5, [x0, x6, lsl #3] 128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c> 12c: f8667826 ldr x6, [x1, x6, lsl #3] 130: 8a0600a5 and x5, x5, x6 134: ca0400a6 eor x6, x5, x4 138: 92800005 mov x5, #0xffffffffffffffff // #-1 13c: 9ac320a5 lsl x5, x5, x3 140: 927ae463 and x3, x3, #0xffffffffffffffc0 144: ea0600a5 ands x5, x5, x6 148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none 14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c> 150: d346fc66 lsr x6, x3, #6 154: f8667805 ldr x5, [x0, x6, lsl #3] 158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c> 15c: f8667826 ldr x6, [x1, x6, lsl #3] 160: 8a0600a5 and x5, x5, x6 164: eb05009f cmp x4, x5 168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any 16c: 91010063 add x3, x3, #0x40 170: eb03005f cmp x2, x3 174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore 178: aa0203e0 mov x0, x2 17c: d65f03c0 ret 180: ca050085 eor x5, x4, x5 184: dac000a5 rbit x5, x5 188: dac010a5 clz x5, x5 18c: 8b0300a3 add x3, x5, x3 190: eb03005f cmp x2, x3 194: 9a839042 csel x2, x2, x3, ls // ls = plast 198: aa0203e0 mov x0, x2 19c: d65f03c0 ret ... 0000000000000238 : 238: a9bf7bfd stp x29, x30, [sp, #-16]! 23c: aa0203e3 mov x3, x2 240: d2800004 mov x4, #0x0 // #0 244: aa0103e2 mov x2, x1 248: 910003fd mov x29, sp 24c: d2800001 mov x1, #0x0 // #0 250: 97ffffb2 bl 118 <_find_next_bit.constprop.1> 254: a8c17bfd ldp x29, x30, [sp], #16 258: d65f03c0 ret Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit(). On A-53 find_first_bit() is almost twice faster than find_next_bit(), according to lib/find_bit_benchmark (thanks to Alexey for testing): GENERIC_FIND_FIRST_BIT=n: [7126084.948181] find_first_bit: 47389224 ns, 16357 iterations [7126085.032315] find_first_bit: 19048193 ns, 655 iterations GENERIC_FIND_FIRST_BIT=y: [ 84.158068] find_first_bit: 27193319 ns, 16406 iterations [ 84.233005] find_first_bit: 11082437 ns, 656 iterations GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation of find_{first,next}_bit(): yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128) ... Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled. Tested-by: Alexey Klimov Signed-off-by: Yury Norov Acked-by: Will Deacon --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 31bd885b79eb..5596eab04092 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -108,6 +108,7 @@ config ARM64 select GENERIC_CPU_AUTOPROBE select GENERIC_CPU_VULNERABILITIES select GENERIC_EARLY_IOREMAP + select GENERIC_FIND_FIRST_BIT select GENERIC_IDLE_POLL_SETUP select GENERIC_IRQ_IPI select GENERIC_IRQ_MULTI_HANDLER