Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3457682ybt; Tue, 23 Jun 2020 02:49:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUed3zF15CO0UrVIOOd+GZ9Dm4RhUUSkrNtD5FkSTu1Fw6lhFQ9E+L5lfcsU6tYDVOmaHb X-Received: by 2002:a17:907:7290:: with SMTP id dt16mr10629854ejc.63.1592905751101; Tue, 23 Jun 2020 02:49:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592905751; cv=none; d=google.com; s=arc-20160816; b=nyKzjNei8o2hFfFeZqWwWA54pqwUEw/auUuaw7frW5usilDccOoflBZYQdNNe/lONq /W9RJNM2JF3480NWGr+x/SXzFy7xyG/bDwPDj6hOhdeaJlmeHoKmrllUS2Eh/t8mSz3f GuK778/evehjPZMhMXpteZBEpLSYRwxC5OF4CoD8B0zGeUfE/VLE4J1mWkNT8QPSFR9u k06t2wS0q2aBDbiiye4IAjoyCj9fVGfwnVNMBbS543xEck0g5QDTE7xOAxNZCxeilGZI HNVUd7V1aao1RGoRebsA2I5KdiJw8kM4UN8kxy8TbO3tfVn4WuzBaboQy13rcDPqFAJP xshg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=1MJWjY3mlbm87zdBOfhE0gBJif9/rXzjsLJXnMx2H9M=; b=reUd1WsneG+QS82E8bo1fwDoxRXwrxGKHahoWakjzmHYdWvT4HRTbi8jkV7TqQbQbl cxvUCyCiC+qDXHbQR0QaHsQSiPT/fmbPrt34u8iscltb9OH0cin6aEWu27n7M3ifWbw1 Krm20lp38OjHHZD84CDK95sDbCHvQpUqa8t1o/OzrMuHslJLDI+j5E+Pg5fV0Dbi5LFL MFXDk03eMjNLNqvezfqY95sanHPbllsVO0qf4AqQUHx2najpeWs2+wExHtDgijOxuxJ5 reHQ0IAUZCW3BAULkV9dIJSmaF/4AmHHQLjeHg4ykC7Q8oHCh8hX0jgqrc3rwX5+5mni Mhuw== 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 d4si11357941edy.517.2020.06.23.02.48.49; Tue, 23 Jun 2020 02:49:11 -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 S1732185AbgFWJrA (ORCPT + 99 others); Tue, 23 Jun 2020 05:47:00 -0400 Received: from foss.arm.com ([217.140.110.172]:48086 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731921AbgFWJq7 (ORCPT ); Tue, 23 Jun 2020 05:46:59 -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 2E0921F1; Tue, 23 Jun 2020 02:46:59 -0700 (PDT) Received: from [192.168.0.110] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0C9993F6CF; Tue, 23 Jun 2020 02:46:56 -0700 (PDT) Subject: Re: [PATCH v5 4/7] arm64: perf: Defer irq_work to IPI_IRQ_WORK To: Mark Rutland 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 References: <20200617113851.607706-1-alexandru.elisei@arm.com> <20200617113851.607706-5-alexandru.elisei@arm.com> <20200622141918.GF88608@C02TD0UTHF1T.local> From: Alexandru Elisei Message-ID: Date: Tue, 23 Jun 2020 10:47:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200622141918.GF88608@C02TD0UTHF1T.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On 6/22/20 3:19 PM, Mark Rutland wrote: > 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. That is much better than my commit message, I will definitely update it with your suggestion. Thanks, Alex > >> 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 >>