Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1189945 > unrolled thread

Re: [RFC][PATCH] perf tests: Add Intel CQM and arch tests

Started byJiri Olsa <jolsa@redhat.com>
First post2015-07-22 15:30 +0200
Last post2015-07-22 16:00 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC][PATCH] perf tests: Add Intel CQM and arch tests Jiri Olsa <jolsa@redhat.com> - 2015-07-22 15:30 +0200
    Re: [RFC][PATCH] perf tests: Add Intel CQM and arch tests Arnaldo Carvalho de Melo <acme@redhat.com> - 2015-07-22 16:00 +0200

#1189945 — Re: [RFC][PATCH] perf tests: Add Intel CQM and arch tests

FromJiri Olsa <jolsa@redhat.com>
Date2015-07-22 15:30 +0200
SubjectRe: [RFC][PATCH] perf tests: Add Intel CQM and arch tests
Message-ID<pP2fV-85a-39@gated-at.bofh.it>
On Wed, Jul 22, 2015 at 11:38:59AM +0100, Matt Fleming wrote:
> From: Matt Fleming <matt.fleming@intel.com>
> 
> Peter reports that it's possible to trigger a WARN_ON_ONCE() in the
> Intel CQM code by combining a hardware event and an Intel CQM (software)
> event into a group. Unfortunately, the perf tools are not able to create
> this bundle and we need to manually construct a test case.
> 
> For posterity, record Peter's proof of concept test case in tools/perf
> so that it presents a model for how we can perform architecture-specific
> tests, or "arch tests", in perf in the future.
> 
> The particular issue triggered in the test case is that when the counter
> for the hardware event overflows and triggers a PMI we'll read both the
> hardware event and the software event counters. Unfortunately, for CQM
> that involves performing an IPI to read the CQM event counters on all
> sockets, which in NMI context triggers the WARN_ON_ONCE().
> 
> This patch is marked as RFC because I'd really like to solicit opinions
> on this approach and hear feedback on whether this is the correct way to
> structure these arch tests. I realise that we've already got tests for
> the TSC, etc that are x86-specific but I didn't want to change the order
> of the tests (say, by moving test__perf_time_to_tsc() into ARCH_TESTS)
> in case that broke some kind of ABI.

I wouldn't consider the order of tests being ABI,
let's break it and watch ;-)

SNIP

> diff --git a/tools/perf/arch/x86/include/arch-tests.h b/tools/perf/arch/x86/include/arch-tests.h
> new file mode 100644
> index 000000000000..9d43f759e014
> --- /dev/null
> +++ b/tools/perf/arch/x86/include/arch-tests.h
> @@ -0,0 +1,13 @@
> +#ifndef ARCH_TESTS_H
> +#define ARCH_TESTS_H
> +
> +/* Tests */
> +int test__intel_cqm_count_nmi_context(void);
> +
> +#define ARCH_TESTS						\
> +	{							\
> +		.desc = "Test intel cqm nmi context read",	\
> +		.func = test__intel_cqm_count_nmi_context,	\
> +	},
> +

hum, I dont like much this being stuffed in macro,
but dont have any technical reason against ;-)

maybe we could add 'struct test arch_tests[]' array, that'd be
initialized by each arch and executed in addition to the current
'struct test tests[]'

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1189959

FromArnaldo Carvalho de Melo <acme@redhat.com>
Date2015-07-22 16:00 +0200
Message-ID<pP2IV-bi-5@gated-at.bofh.it>
In reply to#1189945
Em Wed, Jul 22, 2015 at 03:24:44PM +0200, Jiri Olsa escreveu:
> On Wed, Jul 22, 2015 at 11:38:59AM +0100, Matt Fleming wrote:
> > This patch is marked as RFC because I'd really like to solicit opinions
> > on this approach and hear feedback on whether this is the correct way to
> > structure these arch tests. I realise that we've already got tests for
> > the TSC, etc that are x86-specific but I didn't want to change the order
> > of the tests (say, by moving test__perf_time_to_tsc() into ARCH_TESTS)
> > in case that broke some kind of ABI.
 
> I wouldn't consider the order of tests being ABI,
> let's break it and watch ;-)

yeah
 
> SNIP
 
> > diff --git a/tools/perf/arch/x86/include/arch-tests.h b/tools/perf/arch/x86/include/arch-tests.h
> > +#define ARCH_TESTS						\
> > +	{							\
> > +		.desc = "Test intel cqm nmi context read",	\
> > +		.func = test__intel_cqm_count_nmi_context,	\
> > +	},
> > +
> 
> hum, I dont like much this being stuffed in macro,
> but dont have any technical reason against ;-)
> 
> maybe we could add 'struct test arch_tests[]' array, that'd be
> initialized by each arch and executed in addition to the current
> 'struct test tests[]'

Agreed, that would be cleaner, and we need something like that anyway,
i.e. some way to group tests that run only if certain requirements are
met, i.e. tests that require root permission, arch specific ones, etc.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web