From patchwork Sun Nov 1 13:14:28 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 11872037 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.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 742F5C2D0A3 for ; Sun, 1 Nov 2020 13:18:01 +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 259B0208B6 for ; Sun, 1 Nov 2020 13:18:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="K3+rnfFS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lyAvZCrN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 259B0208B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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: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:In-Reply-To:References:List-Owner; bh=VGlnZWY+nbDtKU7zDJV6M9Zjj96XqJO9OYI51Av9Acs=; b=K3+rnfFSWPkoYn/Nl7mCogeB9n neo7gPre987125bkmPG3ML8xhNcFNUv3Z5UZKUPiPc7i9iDOV9NzuVRsAXcz/r8Eko+BIkClsRY0M OVovgtVxLiP/Z80vbthFf++xq9qKgjl/h8teG8Im89r1eQqJ0usbyrdg4VOKuweecYGSsgC3/En9A 4/TY6CvTlEhuTd0j63e3tE5XJcENXlsqxZRr93wq0Zjogest0C4aDlzenkJrfn6nZ138xsFD1p/GE wkPmucMMonOeJAaRCVb/mlx2qypeObqAvncqGq4t2EL94WaDOx1r8s1urpzAFJSSp4ugANq5S9a80 8CA2DlAg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZDC0-0003Bz-8I; Sun, 01 Nov 2020 13:14:44 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kZDBx-0003AB-84 for linux-arm-kernel@lists.infradead.org; Sun, 01 Nov 2020 13:14:42 +0000 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 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 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201101_081441_377992_8B71712D X-CRM114-Status: GOOD ( 14.49 ) 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: Will Deacon , Peter Zijlstra , Catalin Marinas , Thomas Gleixner , Android Kernel Team , Valentin Schneider Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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(-)