From: Matt Fleming <matt@codeblueprint.co.uk>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Andi Kleen <andi@firstfloor.org>, Vince Weaver <vince@deater.net>,
Vikas Shivappa <vikas.shivappa@linux.intel.com>,
Kanaka Juvva <kanaka.d.juvva@intel.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: Perf tests for hw events
Date: Thu, 22 Jan 2015 17:08:04 +0000 [thread overview]
Message-ID: <20150122170804.GG12079@codeblueprint.co.uk> (raw)
In-Reply-To: <20150122125658.GA2473@krava.brq.redhat.com>
On Thu, 22 Jan, at 01:56:59PM, Jiri Olsa wrote:
> On Thu, Jan 22, 2015 at 12:40:14PM +0000, Matt Fleming wrote:
> > Folks,
> >
> > In the process of writing perf support for Intel's Cache QoS Monitoring
> > feature [0] I've had to write my own userland tests to drive tools/perf
> > and indirectly the kernel internals. I'm now getting requests for these
> > tests from various people and it occurs to me that they should probably
> > live in the kernel tree.
> >
> > The tests I've got do a couple of things like setting up a perf_event
> > cgroup and assigning enough tasks to trigger the RMID recycling code in
> > the CQM driver, ensuring that we can run multiple events simultaneously
> > (that the event scheduling/rotation code works), etc.
> >
> > Does anything like this already exist for hw events? I couldn't find
> > anything specific to hw events from snooping around in tools/perf/tests.
>
> that's the only place for this kind of stuff.. and AFAIK we use
> just some basic HW events like cycles, or software events
OK cool. I just wanted confirmation that tools/perf/tests was the best
place for these tests.
> > We should only test those hw events that are present on a user's
> > machine; there's no sense in emulating things.
>
> agreed.. I remember we were discussing with Arnaldo the strengthening
> of the test framework.. so it would detect what tests are runable
> under current machine and priviledge
>
> IIRC we already have some CPU detection support:
> int __attribute__ ((weak)) get_cpuid(char *buffer, size_t sz);
Aha, excellent. I hadn't noticed this. It should be possible to build
something on top of this.
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2015-01-22 17:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-22 12:40 Perf tests for hw events Matt Fleming
2015-01-22 12:56 ` Jiri Olsa
2015-01-22 17:08 ` Matt Fleming [this message]
2015-01-22 12:59 ` Arnaldo Carvalho de Melo
2015-01-22 17:11 ` Matt Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150122170804.GG12079@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kanaka.d.juvva@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=vikas.shivappa@linux.intel.com \
--cc=vince@deater.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).