All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: "Ashley, William" <wash@amazon.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	will@kernel.org
Subject: Re: armv8pmu: Pending overflow interrupt is discarded when perf event is disabled
Date: Thu, 30 Nov 2023 12:23:13 +0000	[thread overview]
Message-ID: <ZWh-sbrHJu2b-BU6@FVFF77S0Q05N> (raw)
In-Reply-To: <ZWh2pnR_Z5-CKuZb@FVFF77S0Q05N>

On Thu, Nov 30, 2023 at 11:48:54AM +0000, Mark Rutland wrote:
> On Wed, Nov 29, 2023 at 04:35:01PM +0000, Mark Rutland wrote:
> > Does RR set any of the perf_event_attr::exclude_* bits? If not, does RR
> > intentionally count events that occur within the kernel?
> 
> Looking at the test, I see it sets perf_event_attr::exclude_kernel to 1, but
> doesn't set perf_event_attr::exclude_host or perf_event_attr::exclude_hv. I
> think the poorly-defined exclude_* bits are part of the problem here.
> 
> Using your test as-is on my ThunderX2, I can reproduce the period being longer
> than expected by concurrently running the following in a shell:
> 
>   while true; do
>     for C in $(seq 0 63); do
>       taskset -c -p $C ${TEST_PID_HERE};
>     done; 
>   done > /dev/null
> 
> ... resulting in:
> 
> | [mark@gravadlaks:~]% ./counter-overflow                                     
> | Pid 20060 running with period 10000 tolerance 1000
> | Signal #1: last: 0, cur: 10292, max diff: 0
> | Signal #415330: delta of 19999 is outside 10000 +/- 1000
> | Signal #415330: last: 4153290187, cur: 4153310186, max diff: 10292
> | Signal #489879: delta of 19998 is outside 10000 +/- 1000
> | Signal #511842: delta of 20058 is outside 10000 +/- 1000
> | Signal #511842: last: 5118430130, cur: 5118450188, max diff: 19999
> 
> However, if I modify the test to also set perf_event_attr::exclude_host=1, I do
> not see any lost overflows after many minutes. On VHE hosts (like the
> ThunderX2), the host kernel gets counted when perf_event_attr::exclude_host=0,
> even if perf_event_attr::exclude_kernel=1 (which I agree is surprising), so I
> think what's happening is the counters are counting in the host kernel, which
> isn't what RR actually wants regardless.

> I'll continue to look at what we can do kernel-side, but I reckon it's worth
> having RR try the other exclude bits regardless, if that's possible? It would
> be interesting to know whether that helps you under a hypervisor.

Sorry, the above is wrong, and I do not recommend RR goes and changes its
exclude_* settings.

I had misread the logic in armv8pmu_set_event_filter(), but looking again
that's saner than I thought it was, and what was actually happening in my
testing is that exclude_host also filtered host EL0 (userspace), and so the
test received *no* overflow signals.

I'll get back to looking at how we can better capture the overflow when
removing an event.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: "Ashley, William" <wash@amazon.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	will@kernel.org
Subject: Re: armv8pmu: Pending overflow interrupt is discarded when perf event is disabled
Date: Thu, 30 Nov 2023 12:23:13 +0000	[thread overview]
Message-ID: <ZWh-sbrHJu2b-BU6@FVFF77S0Q05N> (raw)
In-Reply-To: <ZWh2pnR_Z5-CKuZb@FVFF77S0Q05N>

On Thu, Nov 30, 2023 at 11:48:54AM +0000, Mark Rutland wrote:
> On Wed, Nov 29, 2023 at 04:35:01PM +0000, Mark Rutland wrote:
> > Does RR set any of the perf_event_attr::exclude_* bits? If not, does RR
> > intentionally count events that occur within the kernel?
> 
> Looking at the test, I see it sets perf_event_attr::exclude_kernel to 1, but
> doesn't set perf_event_attr::exclude_host or perf_event_attr::exclude_hv. I
> think the poorly-defined exclude_* bits are part of the problem here.
> 
> Using your test as-is on my ThunderX2, I can reproduce the period being longer
> than expected by concurrently running the following in a shell:
> 
>   while true; do
>     for C in $(seq 0 63); do
>       taskset -c -p $C ${TEST_PID_HERE};
>     done; 
>   done > /dev/null
> 
> ... resulting in:
> 
> | [mark@gravadlaks:~]% ./counter-overflow                                     
> | Pid 20060 running with period 10000 tolerance 1000
> | Signal #1: last: 0, cur: 10292, max diff: 0
> | Signal #415330: delta of 19999 is outside 10000 +/- 1000
> | Signal #415330: last: 4153290187, cur: 4153310186, max diff: 10292
> | Signal #489879: delta of 19998 is outside 10000 +/- 1000
> | Signal #511842: delta of 20058 is outside 10000 +/- 1000
> | Signal #511842: last: 5118430130, cur: 5118450188, max diff: 19999
> 
> However, if I modify the test to also set perf_event_attr::exclude_host=1, I do
> not see any lost overflows after many minutes. On VHE hosts (like the
> ThunderX2), the host kernel gets counted when perf_event_attr::exclude_host=0,
> even if perf_event_attr::exclude_kernel=1 (which I agree is surprising), so I
> think what's happening is the counters are counting in the host kernel, which
> isn't what RR actually wants regardless.

> I'll continue to look at what we can do kernel-side, but I reckon it's worth
> having RR try the other exclude bits regardless, if that's possible? It would
> be interesting to know whether that helps you under a hypervisor.

Sorry, the above is wrong, and I do not recommend RR goes and changes its
exclude_* settings.

I had misread the logic in armv8pmu_set_event_filter(), but looking again
that's saner than I thought it was, and what was actually happening in my
testing is that exclude_host also filtered host EL0 (userspace), and so the
test received *no* overflow signals.

I'll get back to looking at how we can better capture the overflow when
removing an event.

Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-11-30 12:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-20 18:36 armv8pmu: Pending overflow interrupt is discarded when perf event is disabled Ashley, William
2023-11-20 22:32 ` Ashley, William
2023-11-20 22:32   ` Ashley, William
2023-11-29 16:35   ` Mark Rutland
2023-11-29 16:35     ` Mark Rutland
2023-11-30 11:48     ` Mark Rutland
2023-11-30 11:48       ` Mark Rutland
2023-11-30 12:23       ` Mark Rutland [this message]
2023-11-30 12:23         ` Mark Rutland
2023-12-05 18:14         ` Mark Rutland
2023-12-05 18:14           ` Mark Rutland
2023-12-05 18:33           ` Ashley, William
2023-12-05 18:33             ` Ashley, William

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZWh-sbrHJu2b-BU6@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=wash@amazon.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.