On 29 January 2015 at 17:20, Peter Zijlstra wrote:
> On Thu, Jan 29, 2015 at 05:03:21PM +0200, Alexander Shishkin wrote:
>> > We're already holding ctx->mutex, this should have made lockdep scream.
>>
>> As I mentioned offline, cpuctx->ctx.mutex is set to a lockdep class of
>> its own, so lockdep
On Thu, Jan 29, 2015 at 04:20:22PM +0100, Peter Zijlstra wrote:
> event->ctx is never NULL,
With the one exception of partially initialized events, that is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordo
On Thu, Jan 29, 2015 at 05:03:21PM +0200, Alexander Shishkin wrote:
> > We're already holding ctx->mutex, this should have made lockdep scream.
>
> As I mentioned offline, cpuctx->ctx.mutex is set to a lockdep class of
> its own, so lockdep doesn't see this. It is, of course, still a
> problem.
R
On 29 January 2015 at 13:59, Peter Zijlstra wrote:
> I think that logic fails for per-task events that have a cpu set.
True.
>> +static bool exclusive_event_ok(struct perf_event *event,
>> +struct perf_event_context *ctx)
>> +{
>> + struct pmu *pmu = event->pmu;
>
On Tue, Jan 27, 2015 at 08:03:47PM +0200, Alexander Shishkin wrote:
> +static int account_per_task_counter(struct perf_event *event)
> +{
> + struct pmu *pmu = event->pmu;
> +
> + if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUSIVE))
> + return 0;
> +
> + /*
> + * Prevent
Peter Zijlstra writes:
>
> Yes that'll work.
Ok, let me respin this last patch, with the per-task event counter to
prevent cpu-wide events together with per-task events. The idea is that
cpu-wide events are disallowed when per-task events exist on this pmu
and vice versa. It adds an atomic counte
On Tue, Jan 20, 2015 at 03:20:00PM +0200, Alexander Shishkin wrote:
> > As for the exclusive events, how about something like the code below (on
> > top of the previous exclusive event patch)? The only remaining issue
> > that I see is creating cpu-wide events in the presence of per-thread
> > (eve
Alexander Shishkin writes:
> Peter Zijlstra writes:
>
>> On Wed, Jan 14, 2015 at 02:18:21PM +0200, Alexander Shishkin wrote:
>>> +static __init int pt_init(void)
>>> +{
>>
>>> + pt_pmu.pmu.attr_groups = pt_attr_groups;
>>> + pt_pmu.pmu.task_ctx_nr = perf_hw_context;
>>
>> I just noticed th
Peter Zijlstra writes:
> On Wed, Jan 14, 2015 at 02:18:21PM +0200, Alexander Shishkin wrote:
>> +static __init int pt_init(void)
>> +{
>
>> +pt_pmu.pmu.attr_groups = pt_attr_groups;
>> +pt_pmu.pmu.task_ctx_nr = perf_hw_context;
>
> I just noticed this one, how can this ever work? We wan
On Wed, Jan 14, 2015 at 02:18:21PM +0200, Alexander Shishkin wrote:
> +static __init int pt_init(void)
> +{
> + pt_pmu.pmu.attr_groups = pt_attr_groups;
> + pt_pmu.pmu.task_ctx_nr = perf_hw_context;
I just noticed this one, how can this ever work? We want the PT thing to
always get prog
10 matches
Mail list logo
