All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Raphael Gault <raphael.gault@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Ian Rogers <irogers@google.com>,
	honnappa.nagarahalli@arm.com,
	Itaru Kitayama <itaru.kitayama@gmail.com>
Subject: Re: [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8
Date: Wed, 6 Jan 2021 17:17:50 -0700	[thread overview]
Message-ID: <20210107001750.GA2204700@robh.at.kernel.org> (raw)
In-Reply-To: <20201202145747.GA2381290@robh.at.kernel.org>

On Wed, Dec 02, 2020 at 07:57:47AM -0700, Rob Herring wrote:
> On Fri, Nov 20, 2020 at 02:03:45PM -0600, Rob Herring wrote:
> > On Thu, Nov 19, 2020 at 07:15:15PM +0000, Will Deacon wrote:
> > > On Fri, Nov 13, 2020 at 06:06:33PM +0000, Mark Rutland wrote:
> > > > On Thu, Oct 01, 2020 at 09:01:09AM -0500, Rob Herring wrote:
> > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > > +{
> > > > > +	if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > +		return;
> > > > > +
> > > > > +	if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > > +		on_each_cpu_mask(mm_cpumask(mm), refresh_pmuserenr, NULL, 1);
> > > > > +}

Bump on this again... :)

> > > > 
> > > > I didn't think we kept our mm_cpumask() up-to-date in all cases on
> > > > arm64, so I'm not sure we can use it like this.
> > > > 
> > > > Will, can you confirm either way?
> > > 
> > > We don't update mm_cpumask() as the cost of the atomic showed up in some
> > > benchmarks I did years ago and we've never had any need for the thing anyway
> > > because out TLB invalidation is one or all.
> > 
> > That's good because we're also passing NULL instead of mm which would 
> > crash. So it must be more than it's not up to date, but it's always 0. 
> > It looks like event_mapped on x86 uses mm_cpumask(mm) which I guess was 
> > dropped when copying this code as it didn't work... For reference, the 
> > x86 version of this originated in commit 7911d3f7af14a6.
> > 
> > I'm not clear on why we need to update pmuserenr_el0 here anyways. To 
> > get here userspace has to mmap the event and then unmmap it. If we did 
> > nothing, then counter accesses would not fault until the next context 
> > switch.

Okay, I've come up with a test case where I can trigger this. It's a bit 
convoluted IMO where the thread doing the mmap is different thread from 
reading the counter. Seems like it would be better if we just disabled 
user access if we're not doing calling thread monitoring. We could 
always loosen that restriction later. x86 OTOH was wide open with access 
globally enabled and this hunk of code was part of restricting it some.

> > 
> > If you all have any ideas, I'm all ears. I'm not a scheduler nor perf 
> > hacker. ;)
> 
> Mark, Will, any thoughts on this?

Any reason, this would not work:

static void refresh_pmuserenr(void *mm)
{
	if (mm == current->active_mm)
		perf_switch_user_access(mm);
}

The downside is we'd be doing an IPI on *all* cores for a PMU, not just 
the ones in mm_cpumask() (if that was accurate). But this isn't a fast 
path.

Rob

WARNING: multiple messages have this Message-ID
From: Rob Herring <robh@kernel.org>
To: Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>
Cc: Ian Rogers <irogers@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Raphael Gault <raphael.gault@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	honnappa.nagarahalli@arm.com,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Itaru Kitayama <itaru.kitayama@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8
Date: Wed, 6 Jan 2021 17:17:50 -0700	[thread overview]
Message-ID: <20210107001750.GA2204700@robh.at.kernel.org> (raw)
In-Reply-To: <20201202145747.GA2381290@robh.at.kernel.org>

On Wed, Dec 02, 2020 at 07:57:47AM -0700, Rob Herring wrote:
> On Fri, Nov 20, 2020 at 02:03:45PM -0600, Rob Herring wrote:
> > On Thu, Nov 19, 2020 at 07:15:15PM +0000, Will Deacon wrote:
> > > On Fri, Nov 13, 2020 at 06:06:33PM +0000, Mark Rutland wrote:
> > > > On Thu, Oct 01, 2020 at 09:01:09AM -0500, Rob Herring wrote:
> > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm)
> > > > > +{
> > > > > +	if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > +		return;
> > > > > +
> > > > > +	if (atomic_dec_and_test(&mm->context.pmu_direct_access))
> > > > > +		on_each_cpu_mask(mm_cpumask(mm), refresh_pmuserenr, NULL, 1);
> > > > > +}

Bump on this again... :)

> > > > 
> > > > I didn't think we kept our mm_cpumask() up-to-date in all cases on
> > > > arm64, so I'm not sure we can use it like this.
> > > > 
> > > > Will, can you confirm either way?
> > > 
> > > We don't update mm_cpumask() as the cost of the atomic showed up in some
> > > benchmarks I did years ago and we've never had any need for the thing anyway
> > > because out TLB invalidation is one or all.
> > 
> > That's good because we're also passing NULL instead of mm which would 
> > crash. So it must be more than it's not up to date, but it's always 0. 
> > It looks like event_mapped on x86 uses mm_cpumask(mm) which I guess was 
> > dropped when copying this code as it didn't work... For reference, the 
> > x86 version of this originated in commit 7911d3f7af14a6.
> > 
> > I'm not clear on why we need to update pmuserenr_el0 here anyways. To 
> > get here userspace has to mmap the event and then unmmap it. If we did 
> > nothing, then counter accesses would not fault until the next context 
> > switch.

Okay, I've come up with a test case where I can trigger this. It's a bit 
convoluted IMO where the thread doing the mmap is different thread from 
reading the counter. Seems like it would be better if we just disabled 
user access if we're not doing calling thread monitoring. We could 
always loosen that restriction later. x86 OTOH was wide open with access 
globally enabled and this hunk of code was part of restricting it some.

> > 
> > If you all have any ideas, I'm all ears. I'm not a scheduler nor perf 
> > hacker. ;)
> 
> Mark, Will, any thoughts on this?

Any reason, this would not work:

static void refresh_pmuserenr(void *mm)
{
	if (mm == current->active_mm)
		perf_switch_user_access(mm);
}

The downside is we'd be doing an IPI on *all* cores for a PMU, not just 
the ones in mm_cpumask() (if that was accurate). But this isn't a fast 
path.

Rob

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

  reply	other threads:[~2021-01-07  0:18 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 14:01 [PATCH v4 0/9] libperf and arm64 userspace counter access support Rob Herring
2020-10-01 14:01 ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 1/9] arm64: pmu: Add function implementation to update event index in userpage Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8 Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-11-13 18:06   ` Mark Rutland
2020-11-13 18:06     ` Mark Rutland
2020-11-19 18:35     ` Rob Herring
2020-11-19 18:35       ` Rob Herring
2020-11-19 19:15     ` Will Deacon
2020-11-19 19:15       ` Will Deacon
2020-11-20 20:03       ` Rob Herring
2020-11-20 20:03         ` Rob Herring
2020-11-20 22:08         ` Rob Herring
2020-11-20 22:08           ` Rob Herring
2020-12-02 14:57         ` Rob Herring
2020-12-02 14:57           ` Rob Herring
2021-01-07  0:17           ` Rob Herring [this message]
2021-01-07  0:17             ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 3/9] tools/include: Add an initial math64.h Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 4/9] libperf: Add libperf_evsel__mmap() Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-14 11:05   ` Jiri Olsa
2020-10-14 11:05     ` Jiri Olsa
2020-10-16 21:39     ` Rob Herring
2020-10-16 21:39       ` Rob Herring
2020-10-19 20:15       ` Jiri Olsa
2020-10-19 20:15         ` Jiri Olsa
2020-10-20 14:38         ` Rob Herring
2020-10-20 14:38           ` Rob Herring
2020-10-20 15:35           ` Jiri Olsa
2020-10-20 15:35             ` Jiri Olsa
2020-10-20 17:11             ` Rob Herring
2020-10-20 17:11               ` Rob Herring
2020-10-21 11:24               ` Jiri Olsa
2020-10-21 11:24                 ` Jiri Olsa
2020-11-05 16:19                 ` Rob Herring
2020-11-05 16:19                   ` Rob Herring
2020-11-05 22:41                   ` Jiri Olsa
2020-11-05 22:41                     ` Jiri Olsa
2020-11-06 21:56                     ` Rob Herring
2020-11-06 21:56                       ` Rob Herring
2020-11-11 12:00                       ` Jiri Olsa
2020-11-11 12:00                         ` Jiri Olsa
2020-11-11 14:50                         ` Rob Herring
2020-11-11 14:50                           ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 5/9] libperf: tests: Add support for verbose printing Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 6/9] libperf: Add support for user space counter access Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 7/9] libperf: Add arm64 support to perf_mmap__read_self() Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 8/9] perf: arm64: Add test for userspace counter access on heterogeneous systems Rob Herring
2020-10-01 14:01   ` Rob Herring
2020-10-01 14:01 ` [PATCH v4 9/9] Documentation: arm64: Document PMU counters access from userspace Rob Herring
2020-10-01 14:01   ` Rob Herring

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=20210107001750.GA2204700@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=irogers@google.com \
    --cc=itaru.kitayama@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=raphael.gault@arm.com \
    --cc=will@kernel.org \
    --subject='Re: [PATCH v4 2/9] arm64: perf: Enable pmu counter direct access for perf event on armv8' \
    /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

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.