Messages in this thread | | | Date | Tue, 1 Jun 2021 11:21:43 +0800 | From | Leo Yan <> | Subject | Re: [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers |
| |
On Mon, May 31, 2021 at 05:48:03PM +0200, Peter Zijlstra wrote: > On Mon, May 31, 2021 at 10:53:02PM +0800, Leo Yan wrote: > > Hi Peter, Adrian, > > > > On Thu, May 27, 2021 at 11:57:37AM +0200, Peter Zijlstra wrote: > > > On Thu, May 27, 2021 at 12:24:15PM +0300, Adrian Hunter wrote: > > > > > > > > If all we want is a compiler barrier, then shouldn't that be what we use? > > > > > i.e. barrier() > > > > Sorry for a bit late. Just bring up one question before I respin > > this patch set. > > > > > > I guess you are saying we still need to stop potential re-ordering across > > > > CPUs, so please ignore my comments. > > > > > > Right; so the ordering issue is real, consider: > > > > > > CPU0 (kernel) CPU1 (user) > > > > > > write data read head > > > smp_wmb() smp_rmb() > > > write head read data > > > > One thing should be mentioned is the Linux kernel has _not_ used an > > explict "smb_wmb()" between writing AUX trace data and updating header > > "aux_head". Please see the function perf_aux_output_end(): > > I think we pushed that into the driver. There is nothing the generic > code can do here. > > It is the drivers responsibility of ensuring the data is stable before > calling perf_aux_output_end() or something along those lines.
Thanks for explaination. I reviewed the drivers, some of them have used memory barriers (e.g. Intel-PT, Arm SPE), but some drivers miss to use memory barriers before calling perf_aux_output_end() (Like Arm CoreSight, Intel-bts).
Will address this issue in next patch set.
Thanks, Leo
| |