On Wed, Nov 09, 2016 at 04:51:53PM +0100, Peter Zijlstra wrote:
SNIP
>
> As per a prior mail, the masks on the PMU in question are:
>
> 0x01 - 0001
> 0x03 - 0011
> 0x0e - 1110
> 0x0c - 1100
>
> But since all the masks that have overlap (0xe -> {0xc,0x3}) and (0x3 ->
> 0x1) are of heavier w
On Thu, Nov 10, 2016 at 09:00:13AM +0100, Ingo Molnar wrote:
> Would it be possible to also add debug code (or some other mechanism) to
> disallow
> such buggy EVENT_CONSTRAINT_OVERLAP() definitions?
Should certainly be possible if someone has the time for it I think. The
rules are fairly straigh
* Peter Zijlstra wrote:
> On Wed, Nov 09, 2016 at 03:25:15PM +0100, Robert Richter wrote:
> > On 08.11.16 19:27:39, Peter Zijlstra wrote:
> > > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if
> > > the counter mask of such an event is not a subset of any other counter
> >
On Wed, Nov 09, 2016 at 03:25:15PM +0100, Robert Richter wrote:
> On 08.11.16 19:27:39, Peter Zijlstra wrote:
> > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if
> > the counter mask of such an event is not a subset of any other counter
> > mask of a constraint with an equal
On 08.11.16 19:27:39, Peter Zijlstra wrote:
> The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if
> the counter mask of such an event is not a subset of any other counter
> mask of a constraint with an equal or higher weight".
>
> Esp. that latter part is of interest here I thin
On Tue, Nov 08, 2016 at 05:25:34PM +, Liang, Kan wrote:
> > I think all the 0x3 mask need the overlap flag set, since they clearly
> > overlap
> > with the 0x1 masks. That would improve the scheduling.
> >
>
> How much the overlap hint can improve the scheduling?
> Because there is not only
> >
> > > >
> > > >
> > > > diff --git a/arch/x86/events/intel/uncore_snbep.c
> > > > b/arch/x86/events/intel/uncore_snbep.c
> > > > index 272427700d48..71bc348736bd 100644
> > > > --- a/arch/x86/events/intel/uncore_snbep.c
> > > > +++ b/arch/x86/events/intel/uncore_snbep.c
> > > > @@ -669,7 +669,7
On Tue, Nov 08, 2016 at 04:22:13PM +, Liang, Kan wrote:
>
>
> > >
> > >
> > > diff --git a/arch/x86/events/intel/uncore_snbep.c
> > > b/arch/x86/events/intel/uncore_snbep.c
> > > index 272427700d48..71bc348736bd 100644
> > > --- a/arch/x86/events/intel/uncore_snbep.c
> > > +++ b/arch/x86/even
> >
> >
> > diff --git a/arch/x86/events/intel/uncore_snbep.c
> > b/arch/x86/events/intel/uncore_snbep.c
> > index 272427700d48..71bc348736bd 100644
> > --- a/arch/x86/events/intel/uncore_snbep.c
> > +++ b/arch/x86/events/intel/uncore_snbep.c
> > @@ -669,7 +669,7 @@ static struct event_constraint
Adding Kan who actually maintains the uncore drivers these days.
> Which is two distinct groups, only one of which has overlap. And the one
> with overlap only has 2 overlapping masks, giving a max reties of 1.
Looks reasonable to limit the mask.
Are we sure this problem isn't in the other 0xc m
On Tue, Nov 08, 2016 at 01:20:39PM +0100, Peter Zijlstra wrote:
SNIP
> Now, I would much rather solve this by changing the constraint like the
> below, that yields:
>
> 0x01 - 0001
> 0x03 - 0011
>
> 0x0c - 1100
>
> Which is two distinct groups, only one of which has overlap. And the one
> w
On Tue, Nov 01, 2016 at 04:44:28PM +0100, Jiri Olsa wrote:
> My fuzzer testing hits following warning in the counter scheduling code:
>
> WARNING: CPU: 0 PID: 0 at arch/x86/events/core.c:718
> perf_assign_events+0x2ae/0x2c0
> Call Trace:
>
>dump_stack+0x68/0x93
>__warn+0xcb/0xf0
>
12 matches
Mail list logo
