[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200703134515.GF18953@willie-the-truck>
Date: Fri, 3 Jul 2020 14:45:16 +0100
From: Will Deacon <will@...nel.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: Alexandru Elisei <alexandru.elisei@....com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
mark.rutland@....com, Julien Thierry <julien.thierry@....com>,
Peter Zijlstra <peterz@...radead.org>, maz@...nel.org,
Will Deacon <will.deacon@....com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>, catalin.marinas@....com,
Namhyung Kim <namhyung@...nel.org>,
Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH v5 3/7] arm64: perf: Remove PMU locking
On Fri, Jun 19, 2020 at 01:29:59AM -0700, Stephen Boyd wrote:
> Quoting Alexandru Elisei (2020-06-18 03:51:31)
> > The armv8pmu_{start,stop}() functions are called from the irq handler, so we're
> > safe from preemption in this case. They are also called via
> > pmu->pmu_{enable,disable} callbacks, and I didn't find an explicit contract
> > regarding preemption in include/linux/perf_event.h. I've checked the other call
> > sites, and I didn't find any instances where they are called with preemption
> > enabled, which makes sense as we don't want to disable the PMU on a another CPU by
> > accident.
>
> If they're all callbacks then it's overkill to add this. Presumably it
> is better to enforce this wherever the callbacks are called from so as
> to not litter the callee with random cant_sleep() calls. Probably best
> to ignore my suggestion.
>
> >
> > I would be inclined to add cant_sleep() calls to armv8pmu_{start,stop}(). In the
> > previous iteration, there were WARN_ONs in these functions, and Will said [1] they
> > can be removed because they are per-CPU operations. Will, what do you think about
> > adding the lockdep assertions?
> >
> > [1] https://www.spinics.net/lists/arm-kernel/msg745161.html
> >
>
> If I read it correctly Will is saying the same thing in that thread.
Right, in the cases where perf core already relies on things not being
preemptible, we don't need to add extra checks.
Will
Powered by blists - more mailing lists