All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Stephane Eranian <eranian@google.com>,
	David Ahern <dsahern@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"mingo@elte.hu" <mingo@elte.hu>, Jiri Olsa <jolsa@redhat.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [PATCH] perf mem: add priv level filtering support
Date: Thu, 5 Sep 2013 17:15:08 -0700	[thread overview]
Message-ID: <20130906001508.GA20856@us.ibm.com> (raw)
In-Reply-To: <20130828142112.GE3825@infradead.org>

Arnaldo Carvalho de Melo [acme@redhat.com] wrote:
| Em Wed, Aug 28, 2013 at 03:38:28PM +0200, Stephane Eranian escreveu:
| > On Wed, Aug 28, 2013 at 3:27 PM, Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
| > > So perhaps we should change both to (and add this to 'report' as well):
| > >
| > >     -U, --hide_kernel_symbols   hide kernel symbols
| > >     -K, --hide_user_symbols     hide user symbols
| > >
| > 
| > Well, I don't know what perf top does here but I don't want to hide
| > the samples. I simply don't want to collect them (do not appear
| > in the perf.data file). If that's what is happening in perf top, then
| > I'll be glad to use the same options.
| 
| Indeed, its for different purposes, 'perf top' when used with one of
| those options will still collect samples for all priv levels and will
| just toggle a flag to not zap the ones asked not to show when decaying
| the samples.
| 
| When the user presses 'U' or 'K' on the UI, the flags gets toggled and
| samples start being considered/zapped.
| 
| But my worry here is about consistency accross tools for the single
| letter options, so perhaps if you could use:
| 
|      -U		collect only user level samples
|      -K		collect only kernel level samples
| 
| I think it would stay consistent and clear, what do you think?

But, we use lower case qualifiers :u, :k to select user or kernel mode
monitoring. 

	perf record -e cycles		# both kernel and user
	perf record -e cycles:u ...	# just user

(tools/perf/util/parse-events.c:

        struct event_modifier {
                int eu;
                int ek;
                int eh;
                int eH;
                int eG;
                int precise;
                int exclude_GH;
        };

Will we ever need hypervisor and host monitoring for 'perf mem' ?

Or can we add a '-e' option to 'perf mem' so user can specify the events
and qualfiers same as they do for 'perf record' ?

	perf mem -e mem-loads:u record .....

(this would of course expose the mem-loads and mem-stores events to
the user)

Sukadev


  reply	other threads:[~2013-09-06  0:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-26 13:11 [PATCH] perf mem: add priv level filtering support Stephane Eranian
2013-08-26 22:21 ` David Ahern
2013-08-28 13:20   ` Stephane Eranian
2013-08-28 13:27   ` Arnaldo Carvalho de Melo
2013-08-28 13:38     ` Stephane Eranian
2013-08-28 13:53       ` Stephane Eranian
2013-08-28 14:21       ` Arnaldo Carvalho de Melo
2013-09-06  0:15         ` Sukadev Bhattiprolu [this message]
2013-09-06  3:41         ` Andi Kleen

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=20130906001508.GA20856@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.