From: Peter Zijlstra <peterz@infradead.org>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Leo Yan <leo.yan@linaro.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Andi Kleen <ak@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers
Date: Thu, 27 May 2021 11:45:21 +0200 [thread overview]
Message-ID: <YK9qMWMRWIMfzcPh@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <3c7dcd5d-fddd-5d3b-81ac-cb7b615b0338@intel.com>
On Thu, May 27, 2021 at 11:25:40AM +0300, Adrian Hunter wrote:
> On 27/05/21 11:11 am, Peter Zijlstra wrote:
> > On Thu, May 27, 2021 at 10:54:56AM +0300, Adrian Hunter wrote:
> >> On 19/05/21 5:03 pm, Leo Yan wrote:
> >>> The AUX ring buffer's head and tail can be accessed from multiple CPUs
> >>> on SMP system, so changes to use SMP memory barriers to replace the
> >>> uniprocessor barriers.
> >>
> >> I don't think user space should attempt to be SMP-aware.
> >
> > Uhh, what? It pretty much has to. Since userspace cannot assume UP, it
> > must assume SMP.
>
> Yeah that is what I meant, but consequently we generally shouldn't be
> using functions called smp_<anything>
Of course we should; they're the SMP class of barriers.
> > So ACK on the patch, it's sane and an optimization for both x86 and ARM.
> > Just the Changelog needs work.
>
> If all we want is a compiler barrier, then shouldn't that be what we use?
> i.e. barrier()
No, we want the SMP barriers, smp_rmb() happens to be a compiler barrier
on x86, but it will be dmb(ishld) on Aarrgh64 for example.
prev parent reply other threads:[~2021-05-27 9:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 14:03 [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers Leo Yan
2021-05-19 14:03 ` [PATCH v1 2/2] perf auxtrace: Optimize barriers with load-acquire and store-release Leo Yan
2021-05-31 15:10 ` Leo Yan
2021-05-31 15:55 ` Peter Zijlstra
2021-05-31 19:03 ` Adrian Hunter
2021-06-01 6:33 ` Leo Yan
2021-06-01 6:58 ` Peter Zijlstra
2021-06-01 9:07 ` Adrian Hunter
2021-06-01 9:17 ` Peter Zijlstra
2021-06-01 9:45 ` Adrian Hunter
2021-06-01 9:48 ` Peter Zijlstra
2021-06-01 14:56 ` Leo Yan
2021-06-01 6:48 ` Peter Zijlstra
2021-05-27 7:54 ` [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers Adrian Hunter
2021-05-27 8:11 ` Peter Zijlstra
2021-05-27 8:25 ` Adrian Hunter
2021-05-27 9:24 ` Adrian Hunter
2021-05-27 9:57 ` Peter Zijlstra
2021-05-31 14:53 ` Leo Yan
2021-05-31 15:48 ` Peter Zijlstra
2021-06-01 3:21 ` Leo Yan
2021-05-27 9:45 ` Peter Zijlstra [this message]
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=YK9qMWMRWIMfzcPh@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@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.