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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_GIT autolearn=no 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 DE7A7C2D0A3 for ; Sun, 1 Nov 2020 13:14:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 880A922243 for ; Sun, 1 Nov 2020 13:14:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604236482; bh=0TxCwqvhZ/rly8WLeRqIopvHRJn6Q9BPMUln/824/mc=; h=From:To:Cc:Subject:Date:List-ID:From; b=T1c7ncrh9V1sWkeUHN/601rkSkeEzsDz3WjmcbYGPlNolmlILnKr3YH6/Dxt04kpP WL2MWBBYKrDy+Z6JsowOdmqbCS6i+NtmrDNS7KuUUM1B4lWDwnj+JAMhH+1u0FesLc dOUemGQqnSpT4MuWhPscPG/I4gCAUvSdCF6+56Yg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726697AbgKANOl (ORCPT ); Sun, 1 Nov 2020 08:14:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:57098 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbgKANOk (ORCPT ); Sun, 1 Nov 2020 08:14:40 -0500 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 5EBEF20870; Sun, 1 Nov 2020 13:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604236480; bh=0TxCwqvhZ/rly8WLeRqIopvHRJn6Q9BPMUln/824/mc=; h=From:To:Cc:Subject:Date:From; b=lyAvZCrNgqsRwxIdnMaywVpp/6BNrGy9TFuAw7EDcJkTthjDXKvM5sba5CsyLKtVS LsUVOu1YV0yjeFo4RJxZ6RRV//4JNMEh9IcRczbsDbbfJCHy6oOSyQ2qN8lJ23k9du jJjSuAwaq05m7DBzavHkEApYtcDjxzE5Ckzqqwos= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kZDBu-006QYT-3n; Sun, 01 Nov 2020 13:14:38 +0000 From: Marc Zyngier To: LAK , linux-kernel Cc: Will Deacon , Catalin Marinas , Thomas Gleixner , Valentin Schneider , Peter Zijlstra , Android Kernel Team Subject: [PATCH 0/2] arm64: Allow the rescheduling IPI to bypass irq_enter/exit Date: Sun, 1 Nov 2020 13:14:28 +0000 Message-Id: <20201101131430.257038-1-maz@kernel.org> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, tglx@linutronix.de, Valentin.Schneider@arm.com, peterz@infradead.org, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vincent recently reported [1] that 5.10-rc1 showed a significant regression when running "perf bench sched pipe" on arm64, and pinpointed it to the recent move to handling IPIs as normal interrupts. The culprit is the use of irq_enter/irq_exit around the handling of the rescheduling IPI, meaning that we enter the scheduler right after the handling of the IPI instead of deferring it to the next preemption event. This accounts for most of the overhead introduced. On architectures that have architected IPIs at the CPU level (x86 being the obvious one), the absence of irq_enter/exit is natural. ARM (both 32 and 64bits) mimicked this behaviour by having some arch-specific handling for the interrupts that are used to implement IPIs. Moving IPIs on the normal interrupt path introduced the regression. This couple of patches try to acknowledge the fact that some IPIs are "special", in the sense that they don't need to follow the standard interrupt handling flow. The good news is that it cures the regression on arm64, and could be similarly beneficial to both 32bit ARM, MIPS, or any other architecture that uses a unique IRQ to represent the scheduler IPI. The bad news is that these patches are ugly as sin, and I really don't like them. I specially hate that they can give driver authors the idea that they can make random interrupts "faster". Comments, suggestions and hate mails appreciated, as always. M. [1] https://lore.kernel.org/r/CAKfTPtDjPpri5Gt6kLeFp_B_zJUZ5DYXEqtJ+0VKohU-y9bFEQ@mail.gmail.com Marc Zyngier (2): genirq: Allow an interrupt to be marked as 'naked' arm64: Mark the recheduling IPI as naked interrupt arch/arm64/kernel/smp.c | 4 ++++ include/linux/irq.h | 4 +++- kernel/irq/debugfs.c | 1 + kernel/irq/irqdesc.c | 17 ++++++++++++----- kernel/irq/settings.h | 7 +++++++ 5 files changed, 27 insertions(+), 6 deletions(-) -- 2.28.0