On Tue, Mar 10, 2015 at 03:36:08PM +, Mark Rutland wrote:
> On the assumption that the patch is otherwise OK, how about the commit
> message below?
Yeah, that'll do fine. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
On Tue, Mar 10, 2015 at 12:53:51PM +, Peter Zijlstra wrote:
> On Tue, Mar 10, 2015 at 12:05:21PM +, Mark Rutland wrote:
> > On Tue, Mar 10, 2015 at 11:27:23AM +, Peter Zijlstra wrote:
> > > On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
> > > > From: "Suzuki K. Poulo
> I think we could still solve this problem by deferring the 'context'
> validation to the core. The PMUs could validate the group, within its
> context. i.e, if it can accommodate its events as a group, during
> event_init. The problem we face now, is encountering an event from a
> different PM
On 10/03/15 13:00, Peter Zijlstra wrote:
On Tue, Mar 10, 2015 at 01:53:51PM +0100, Peter Zijlstra wrote:
It would be nicer if we could prevent this in the core so we're not
reliant on every PMU driver doing the same verification. My initial
thought was that seemed like unnecessary duplication of
> So the problem is that event_init() is what will return the pmu, so we
> cannot make decisions on it until after that returns.
I took a look into hacking something into perf_try_init_event, but it
ends up duplicating all of the existing tests and looks really out of
place.
> Maybe we can pull o
On Tue, Mar 10, 2015 at 01:53:51PM +0100, Peter Zijlstra wrote:
> > It would be nicer if we could prevent this in the core so we're not
> > reliant on every PMU driver doing the same verification. My initial
> > thought was that seemed like unnecessary duplication of the ctx checking
> > above, but
On Tue, Mar 10, 2015 at 12:05:21PM +, Mark Rutland wrote:
> On Tue, Mar 10, 2015 at 11:27:23AM +, Peter Zijlstra wrote:
> > On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
> > > From: "Suzuki K. Poulose"
> > >
> > > Don't allow grouping hardware events from different PM
On Tue, Mar 10, 2015 at 11:27:23AM +, Peter Zijlstra wrote:
> On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
> > From: "Suzuki K. Poulose"
> >
> > Don't allow grouping hardware events from different PMUs
> > (eg. CCI + CPU).
>
> Uhm, how does this work? If we have multip
On 10/03/15 11:27, Peter Zijlstra wrote:
On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Uhm, how does this work? If we have multiple hardware PMUs we'll stop
scheduling e
On Mon, Mar 09, 2015 at 12:46:30PM +, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> Don't allow grouping hardware events from different PMUs
> (eg. CCI + CPU).
Uhm, how does this work? If we have multiple hardware PMUs we'll stop
scheduling events after the first failed event sch
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
From: "Suzuki K. Poulose"
Don't allow grouping hardware events from different PMUs
(eg. CCI + CPU).
Fixes a crash triggered by perf_fuzzer on Linux-4.0-rc2,
with CCI PMU turned on. The validate_event(), after certain checks,
assumes that the given hardware pmu event belongs to armpmu,
which may
12 matches
Mail list logo
