On Wed, Oct 22, 2014 at 02:31:51PM +0200, Jiri Olsa wrote: > On Thu, Oct 09, 2014 at 06:34:40PM +0200, Stephane Eranian wrote: > > From: Maria Dimakopoulou <[email protected]> > > SNIP > > > +static struct event_constraint * > > +intel_get_excl_constraints(struct cpu_hw_events *cpuc, struct perf_event > > *event, > > + int idx, struct event_constraint *c) > > +{ > > + struct event_constraint *cx; > > + struct intel_excl_cntrs *excl_cntrs = cpuc->excl_cntrs; > > + struct intel_excl_states *xl, *xlo; > > + int is_excl, i; > > SNIP > > > + /* > > + * Modify static constraint with current dynamic > > + * state of thread > > + * > > + * EXCLUSIVE: sibling counter measuring exclusive event > > + * SHARED : sibling counter measuring non-exclusive event > > + * UNUSED : sibling counter unused > > + */ > > + for_each_set_bit(i, cx->idxmsk, X86_PMC_IDX_MAX) { > > + /* > > + * exclusive event in sibling counter > > + * our corresponding counter cannot be used > > + * regardless of our event > > + */ > > + if (xl->state[i] == INTEL_EXCL_EXCLUSIVE) > > + __clear_bit(i, cx->idxmsk); > > if we want to check sibling counter, shouldn't we check xlo->state[i] > instead? like > > if (xlo->state[i] == INTEL_EXCL_EXCLUSIVE) > __clear_bit(i, cx->idxmsk); > > > and also in condition below?
any comment on this? I'm curious, because it'd enlighten me on how this is supposed to work ;-) I dont understand why you update the sibling's counter state instead of the current cpuc->excl_thread_id HT, like in intel_commit_scheduling while you hold lock for the current HT state could you please comment, I must be missing something thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
