Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp467824pxa; Wed, 19 Aug 2020 06:35:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmiJjOEzduuq4ErF2TqeDM77iEXLu1i7PELR+XRvvv1v0INXUMHsHtVSixGKGtTcmrfxDA X-Received: by 2002:a17:906:c7c8:: with SMTP id dc8mr24540605ejb.285.1597844104344; Wed, 19 Aug 2020 06:35:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597844104; cv=none; d=google.com; s=arc-20160816; b=QFSZvWBeD4TPTDr7A/KnvR6QCFKc1oiYeNQ4sPUIDCctC75EB4UPOL0f8RKPnYsdAD EL14wvnNy44gPVRarZn2zqNs/v6TWU/dnNgxsHYY+qXxNK2zHhBDEYBjn8KsSdb/F5NT v4ou7cbYCUOszVO72c/w0lY2XZNPevpCIs44ljd4GQIcV4m3TfJslIa0g9E8Oejhcu3G p8bi7hpuq3XKX0cg05kuZUumDaEszT5n+SlAIMYu6hmauXv/P6NVcpBwB1awjy99akeg ppinrS7YbxzurkZ5pB/jVnQENW/p3umHyXxdg/k8puxq9SlQDTzQBQRkfRVJbU3B+TSj f09Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=aaVHkF4iIzSprDS15st1TiUg3wQ2XnuFsL4qpekSFv4=; b=PAsEE5JwXcWouU7UZ0bs3fs9VMhZeZ042ntM80UEVgutw9mkITktNmoQY1Rn8tvduZ Fk906tZ5TNT9UGoAcgDPz81IOW2kpMGgFkC1kjOjvPq3XffatFvlrnw8nQxJoBDgFJo7 XdSDXvjPZSJec2fRCJgGu/q4VVKoOO2iL024ngXauZzmLGLXOE2IwhB1rGH4sQty2eJx LIaM0l3ipD1tYXnLsQXOA3JyuSFVayZmxcmgx+d7UAum4wO4FqOLQO0/G1ApWWt7/jSz uFBmumY6UUyx7CnLAVjmST8hLpYEe7/xURoH84zb5YVOwthipvKabz6A8MUP4YAW1cm6 3nfA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si14543132eji.444.2020.08.19.06.34.40; Wed, 19 Aug 2020 06:35:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728573AbgHSNdv (ORCPT + 99 others); Wed, 19 Aug 2020 09:33:51 -0400 Received: from foss.arm.com ([217.140.110.172]:36938 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728529AbgHSNdi (ORCPT ); Wed, 19 Aug 2020 09:33:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9C96312FC; Wed, 19 Aug 2020 06:33:37 -0700 (PDT) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 793E53F71F; Wed, 19 Aug 2020 06:33:35 -0700 (PDT) From: Alexandru Elisei To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Cc: mark.rutland@arm.com, maz@kernel.org, will@kernel.org, catalin.marinas@arm.com, swboyd@chromium.org, sumit.garg@linaro.org, Julien Thierry , Julien Thierry , Will Deacon , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim Subject: [PATCH v6 4/7] arm64: perf: Defer irq_work to IPI_IRQ_WORK Date: Wed, 19 Aug 2020 14:34:16 +0100 Message-Id: <20200819133419.526889-5-alexandru.elisei@arm.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200819133419.526889-1-alexandru.elisei@arm.com> References: <20200819133419.526889-1-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Julien Thierry When handling events, armv8pmu_handle_irq() calls perf_event_overflow(), and subsequently calls irq_work_run() to handle any work queued by perf_event_overflow(). As perf_event_overflow() raises IPI_IRQ_WORK when queuing the work, this isn't strictly necessary and the work could be handled as part of the IPI_IRQ_WORK handler. In the common case the IPI handler will run immediately after the PMU IRQ handler, and where the PE is heavily loaded with interrupts other handlers may run first, widening the window where some counters are disabled. In practice this window is unlikely to be a significant issue, and removing the call to irq_work_run() would make the PMU IRQ handler NMI safe in addition to making it simpler, so let's do that. Cc: Julien Thierry Cc: Will Deacon Cc: Mark Rutland Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Catalin Marinas Signed-off-by: Julien Thierry [Reworded commit] Signed-off-by: Alexandru Elisei --- arch/arm64/kernel/perf_event.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c index 80744c2f1454..5bf283518981 100644 --- a/arch/arm64/kernel/perf_event.c +++ b/arch/arm64/kernel/perf_event.c @@ -780,20 +780,16 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu) if (!armpmu_event_set_period(event)) continue; + /* + * Perf event overflow will queue the processing of the event as + * an irq_work which will be taken care of in the handling of + * IPI_IRQ_WORK. + */ if (perf_event_overflow(event, &data, regs)) cpu_pmu->disable(event); } armv8pmu_start(cpu_pmu); - /* - * Handle the pending perf events. - * - * Note: this call *must* be run with interrupts disabled. For - * platforms that can have the PMU interrupts raised as an NMI, this - * will not work. - */ - irq_work_run(); - return IRQ_HANDLED; } -- 2.28.0