[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220227135444.GB107053@leoy-ThinkPad-X240s>
Date: Sun, 27 Feb 2022 21:54:44 +0800
From: Leo Yan <leo.yan@...aro.org>
To: Ali Saidi <alisaidi@...zon.com>
Cc: german.gomez@....com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, andrew.kilroy@....com,
benh@...nel.crashing.org, james.clark@....com,
john.garry@...wei.com, jolsa@...hat.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, mark.rutland@....com,
mathieu.poirier@...aro.org, mingo@...hat.com, namhyung@...nel.org,
peterz@...radead.org, will@...nel.org
Subject: Re: [PATCH 2/2] perf arm-spe: Parse more SPE fields and store source
On Tue, Feb 22, 2022 at 07:29:43PM +0000, Ali Saidi wrote:
[...]
> >So I am just wandering if we can set the field
> >sample::data_src::mem_lock for atomic operations, like:
> >
> > data_src.mem_op = PERF_MEM_OP_LOAD;
> > data_src.mem_lock = PERF_MEM_LOCK_ATOMIC;
> >
> >The field "mem_lock" is only two bits, we can consider to extend the
> >structure with an extra filed "mem_lock_ext" if it cannot meet our
> >requirement.
>
> These are for the LOCK instruction on x86. I don't know that we want to
> overload the meaning here. Minimally there is value in differentiating
> exclusives vs atomics.
Good point. Can we consider to add new filed data_src.atomic with
below types?
PERF_MEM_ATOMIC_INST -> Atomic operations
PERF_MEM_ATOMIC_EXCL -> Load-Exclusive/Store-Exclusive
PERF_MEM_ATOMIC_ACQUIRE_RELEASE ->Load-Acquire/Store-Release
Thanks,
Leo
Powered by blists - more mailing lists