[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBTm7L-dqjEz6ECuXsJNLReC+zuu1uu6ceZkpksTUTaycg@mail.gmail.com>
Date: Tue, 26 May 2015 06:44:31 -0700
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Vince Weaver <vincent.weaver@...ne.edu>,
Jiri Olsa <jolsa@...hat.com>,
"Liang, Kan" <kan.liang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Hunter <ahh@...gle.com>,
Maria Dimakopoulou <maria.n.dimakopoulou@...il.com>
Subject: Re: [PATCH v2 01/11] perf,x86: Fix event/group validation
On Tue, May 26, 2015 at 6:22 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, May 26, 2015 at 05:25:59AM -0700, Stephane Eranian wrote:
>> > IIRC the problem was that the copy from c2 into c1:
>> >
>> > if (c1 && (c1->flags & PERF_X86_EVENT_DYNAMIC)) {
>> > bitmap_copy(c1->idxmsk, c2->idxmsk, X86_PMC_IDX_MAX);
>> > c1->weight = c2->weight;
>> > c2 = c1;
>> > }
>> >
>> > is incomplete. For instance, flags is not copied, and some code down the
>> > line might check that and get wrong flags.
>> >
>> Ok, now I remember this code. It has to do with incremental scheduling.
>> Suppose E1, E2, E3 events where E1 is exclusive. The first call is
>> for scheduling E1. It gets to get_event_constraint() which "allocates" a
>> dynamic constraint. The second call tries to schedule E1, E2. But the
>> second time for E1, you already have the dynamic constraint allocated, so
>> this code is reusing the constraint storage and just updates the bitmask
>> and weight.
>>
>> Now, that the storage is not actually dynamic (kmalloc'd), but taken from a
>> fixed size array in cpuc, I believe we can simplify this and "re-allocate"
>> the constraint for each incremental call to intel_get_event_constraints().
>> Do you agree?
>
> That would probably work, the whole incremental thing seems superfluous
> to me.
Well, you could pass the whole lists (4) of events in one call and
let the arch level
sort it out. It could do one pass and stop at first error to get a
fixed bound like
today. But it would need to deal with groups as well...so not so easy and why
repeat the group processing for each arch?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists