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
Add support for Intel Processor Trace (PT) to kernel's perf events.
PT is an extension of Intel Architecture that collects information about
software execuction such as control flow, execution modes and timings and
formats it into highly compressed binary packets. Even being compressed,
these packe
11 matches
Mail list logo