linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vince Weaver <vweaver1@eecs.utk.edu>
To: Ingo Molnar <mingo@elte.hu>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Stephane Eranian <eranian@gmail.com>,
	Lin Ming <ming.m.lin@intel.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 1/1] perf tools: Add missing user space support for config1/config2
Date: Mon, 25 Apr 2011 13:12:15 -0400 (EDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1104251307010.12389@cl320.eecs.utk.edu> (raw)
In-Reply-To: <20110422080604.GA22611@elte.hu>


sorry for the late reply on this thread, it happened inconveniently over 
the long weekend.


On Fri, 22 Apr 2011, Ingo Molnar wrote:

> But this kind of usability is absolutely unacceptable - users should not
> be expected to type in magic, CPU and model specific incantations to get
> access to useful hardware functionality.

That's why people use libpfm4.  or PAPI.  And they do.

Current PAPI snapshots support offcore response on recent git kernels.
With full names, no hex values, thanks to libpfm4.

All the world is not perf.

> The proper solution is to expose useful offcore functionality via
> generalized events - that way users do not have to care which specific
> CPU model they are using, they can use the conceptual event and not some
> model specific quirky hexa number.

No no no no.

Blocking access to raw events is the wrong idea.  If anything, the whole 
"generic events" thing in the kernel should be ditched.  Wrong events are 
used at times (see AMD branch events a few releases back, now Nehalem 
cache events).  This all belongs in userspace, as was pointed out at the 
start.  The kernel has no business telling users which perf events are 
interesting, or limiting them!  What is this, windows?

If you do block access to any raw events, we're going to have to start 
recommending people ditch perf_events and start patching the kernel with 
perfctr again.  We already do for P4/netburst users, as Pentium 4 support 
is currently hosed due to NMI event conflicts.

Also with perfctr it's much easier to get low-latency access to the 
counters.  See:
  http://web.eecs.utk.edu/~vweaver1/projects/papi-cost/

Vince

  parent reply	other threads:[~2011-04-25 17:25 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21 17:41 [GIT PULL 0/1] perf/urgent Fix missing support for config1/config2 Arnaldo Carvalho de Melo
2011-04-21 17:41 ` [PATCH 1/1] perf tools: Add missing user space " Arnaldo Carvalho de Melo
2011-04-22  6:34   ` Ingo Molnar
2011-04-22  8:06     ` Ingo Molnar
2011-04-22 21:37       ` Peter Zijlstra
2011-04-22 21:54         ` Peter Zijlstra
2011-04-22 22:19           ` Peter Zijlstra
2011-04-22 23:54             ` Andi Kleen
2011-04-23  7:49               ` Peter Zijlstra
2011-04-22 22:57           ` Peter Zijlstra
2011-04-23  0:00             ` Andi Kleen
2011-04-23  7:50               ` Peter Zijlstra
2011-04-23  8:13         ` Ingo Molnar
2011-07-01 15:23         ` [tip:perf/core] perf, arch: Add generic NODE cache events tip-bot for Peter Zijlstra
2011-04-25 17:12       ` Vince Weaver [this message]
2011-04-25 17:54         ` [PATCH 1/1] perf tools: Add missing user space support for config1/config2 Ingo Molnar
2011-04-25 21:46           ` Vince Weaver
2011-04-25 22:12             ` Andi Kleen
2011-04-26  7:23               ` Ingo Molnar
2011-04-26  7:38             ` Ingo Molnar
2011-04-26 20:51               ` Vince Weaver
2011-04-27  6:52                 ` Ingo Molnar
2011-04-28 22:16                   ` Vince Weaver
2011-04-28 23:30                     ` Thomas Gleixner
2011-04-29  2:28                     ` Andi Kleen
2011-04-29 19:32                     ` Ingo Molnar
2011-04-26  9:49             ` Peter Zijlstra
2011-04-26  9:25         ` Peter Zijlstra
2011-04-26 20:33           ` Vince Weaver
2011-04-26 21:19             ` Cyrill Gorcunov
2011-04-26 21:25               ` Don Zickus
2011-04-26 21:33                 ` Cyrill Gorcunov
2011-04-27  6:43             ` Ingo Molnar
2011-04-28 22:10               ` Vince Weaver
2011-04-22 16:22     ` Andi Kleen
2011-04-22 19:54       ` Ingo Molnar
2011-04-22  8:47 Stephane Eranian
2011-04-22  9:23 ` Ingo Molnar
2011-04-22  9:41   ` Stephane Eranian

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=alpine.DEB.2.00.1104251307010.12389@cl320.eecs.utk.edu \
    --to=vweaver1@eecs.utk.edu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=eranian@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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).