Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2800366ybt; Mon, 22 Jun 2020 07:22:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzdCOzTtkmsQjAodZX5eAr6UcQ9iBgMywRAtyW7aX3QLG6kIraVrQWG15KHh5E+j9Y0tGv X-Received: by 2002:a50:ec0f:: with SMTP id g15mr17590207edr.359.1592835728203; Mon, 22 Jun 2020 07:22:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592835728; cv=none; d=google.com; s=arc-20160816; b=INGEqNia4sLZjyHY86v5cU6gul0wdK83eSFdA0yux4c6RP9Ep1cw6SgcKTXeUdhCA0 uqd+oicJhWUgOylRHo0vHwtYoxNgvzaBjKDkf1rHxLZ1KInD6mSWyGgphmJ4zgCJ9Rnx HqKLHL6VSQ6k00ikkvCA2B72SFLTUWcNF+8u8C91scolvVtgK/Y4mSivXzAh1Hr8Yl/n 7eu9J7pJF/VSIztjmrFWtsa+J0C98/rF75ylpnu27nDgo7hNrJ85PWGrUlOvnT2UF2TP wUUQNorIAJ56emVDPkrNzi5WYWVMlwYGADgQ8oOsF1GIiGymem6ZIZl++OkL1ivS/ymS mnQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=7Sbr2BKa8nO0mVq2QVvq04fqZXz7gjWn13IjcSBVOlk=; b=HmsbEbOeQTtvSFnFqqAHIHxv+O3oFbNlenHtFOa4twMNQbQ3HzRVXa6nDPrHq8RYqg UGWVHbyHHfGsBX1k6t+5/gkK6YYRdS2XGnWCW8nh2+4htEq1Tg2MttNSrKOKeky5UZag kGIyHHX5AWkmtysSioo78w4MBZP+FYPQYhUgv9IyZVIzkdSLMEtjACo/SHttFO8StRwW gma7C9XUJhhiVIkX32NiP6gtxvtPAIx53vazArHKMe1TKTCYoDe053EYr/J4XOLNsRkO js0rq2DBK8uAbSb6MiLz309hGTbgj1/9DJ5ro8rDaUasaM3WebL5vvfl0zWK3ZZuOkId /WZw== 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 lf3si8868922ejb.350.2020.06.22.07.21.45; Mon, 22 Jun 2020 07:22:08 -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 S1729262AbgFVOTZ (ORCPT + 99 others); Mon, 22 Jun 2020 10:19:25 -0400 Received: from foss.arm.com ([217.140.110.172]:36144 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728753AbgFVOTY (ORCPT ); Mon, 22 Jun 2020 10:19:24 -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 B3BAB31B; Mon, 22 Jun 2020 07:19:23 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.15.132]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 052893F6CF; Mon, 22 Jun 2020 07:19:20 -0700 (PDT) Date: Mon, 22 Jun 2020 15:19:18 +0100 From: Mark Rutland To: Alexandru Elisei Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maz@kernel.org, will@kernel.org, catalin.marinas@arm.com, Julien Thierry , Julien Thierry , Will Deacon , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim Subject: Re: [PATCH v5 4/7] arm64: perf: Defer irq_work to IPI_IRQ_WORK Message-ID: <20200622141918.GF88608@C02TD0UTHF1T.local> References: <20200617113851.607706-1-alexandru.elisei@arm.com> <20200617113851.607706-5-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617113851.607706-5-alexandru.elisei@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 17, 2020 at 12:38:48PM +0100, Alexandru Elisei wrote: > From: Julien Thierry > > perf_event_overflow() can queue an irq_work on the current PE, which is > executed via an IPI. Move the processing of the irq_work from the PMU IRQ > handler to the IPI handler, which gets executed immediately afterwards. > > This also makes the IRQ handler NMI safe, because it removes the call to > irq_work_run(). It wasn't entirely clear to me what the situation was today, and why this was sound. How about the following to spell that out more explicitly: | 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 queing 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. Thanks, Mark. > > 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 a6195022be7d..cf1d92030790 100644 > --- a/arch/arm64/kernel/perf_event.c > +++ b/arch/arm64/kernel/perf_event.c > @@ -750,20 +750,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.27.0 >