[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190528134354.GP2623@hirez.programming.kicks-ass.net>
Date: Tue, 28 May 2019 15:43:54 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: kan.liang@...ux.intel.com
Cc: acme@...nel.org, mingo@...hat.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, jolsa@...nel.org, eranian@...gle.com,
alexander.shishkin@...ux.intel.com, ak@...ux.intel.com
Subject: Re: [PATCH 4/9] perf/x86/intel: Support hardware TopDown metrics
On Tue, May 21, 2019 at 02:40:50PM -0700, kan.liang@...ux.intel.com wrote:
> @@ -3287,6 +3304,13 @@ static int core_pmu_hw_config(struct perf_event *event)
> return intel_pmu_bts_config(event);
> }
>
> +#define EVENT_CODE(e) (e->attr.config & INTEL_ARCH_EVENT_MASK)
> +#define is_slots_event(e) (EVENT_CODE(e) == 0x0400)
> +#define is_perf_metrics_event(e) \
> + (((EVENT_CODE(e) & 0xff) == 0xff) && \
> + (EVENT_CODE(e) >= 0x01ff) && \
> + (EVENT_CODE(e) <= 0x04ff))
> +
That is horrific.. (e & INTEL_ARCH_EVENT_MASK) & 0xff is just daft,
that should be: (e & ARCH_PERFMON_EVENTSEL_EVENT).
Also, we already have fake events for event=0, see FIXED2, why are we
now using event=0xff ?
Powered by blists - more mailing lists