public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: mingo@redhat.com, hpa@zytor.com, eranian@google.com,
	linux-kernel@vger.kernel.org, acme@redhat.com,
	robert.richter@amd.com, tglx@linutronix.de,
	cjashfor@linux.vnet.ibm.com, mingo@elte.hu,
	linux-tip-commits@vger.kernel.org
Subject: Re: [tip:perf/urgent] perf sched: Fix list of events, dropping unsupported ':r' modifier
Date: Wed, 03 Aug 2011 14:05:35 +0200	[thread overview]
Message-ID: <1312373135.1147.308.camel@twins> (raw)
In-Reply-To: <20110803115703.GB5768@somewhere.redhat.com>

On Wed, 2011-08-03 at 13:57 +0200, Frederic Weisbecker wrote:
> On Wed, Aug 03, 2011 at 01:42:21PM +0200, Peter Zijlstra wrote:
> > On Wed, 2011-08-03 at 13:37 +0200, Frederic Weisbecker wrote:
> > > On Wed, Aug 03, 2011 at 12:59:21PM +0200, Peter Zijlstra wrote:
> > > > On Fri, 2011-01-14 at 07:25 +0000, tip-bot for Stephane Eranian wrote:
> > > > > Looks to me like the :r modifier is not supported anymore, so remove it from
> > > > > the list of events. 
> > > > 
> > > > acme, why is that anyway? -R is a fun way to save some typing, but not
> > > > supporting :r anymore takes away the option of not getting
> > > > PERF_SAMPLE_RAW output for every event.
> > > 
> > > Because it was very non obvious for people to select this -R or :r
> > > every time they wanted to use trace events for tracing. I think
> > > there was complaints about that. Moreover nobody seemed to use
> > > trace events for non-tracing (perf report, top, annotate, ...)
> > > so we decided to always have RAW records so that it works for
> > > every cases...unless we lose events because of that.
> > > 
> > > We can still bring an option to force disabling of raw records.
> > 
> > That just doesn't compute, they still have to use -R, so what's the harm
> > in also having :r?
> 
> Nope -R is the default/forced behaviour already.
> But even if it wasn't I don't see much the point of ":r". Who wants
> to run two trace events and only record the traces of one?

[root@westmere linux-2.6]# grep raw_samples tools/perf/builtin-record.c | head -1
static bool                     raw_samples                     =  false;

is what tip/master is showing me..

> > Also taking away options just because it confuses people sounds like
> > gnome, lets just not go there.
> 
> You're right but options should be there only to be able to override
> sane default common uses. And not the opposite. And the common use
> of trace events is for tracing.
> 
> We should rather enable tracing by default and disable it through
> an option. Like --no-trace or so.

you smoking some expensive stuff, right?

  reply	other threads:[~2011-08-03 12:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12  9:29 [BUG] perf sched broken Stephane Eranian
2011-01-12 12:11 ` Arnaldo Carvalho de Melo
2011-01-12 19:10   ` Corey Ashford
2011-01-12 19:41 ` Corey Ashford
2011-01-12 19:52   ` Stephane Eranian
2011-01-12 20:22     ` Corey Ashford
2011-01-12 22:35 ` Corey Ashford
2011-01-12 22:38   ` Stephane Eranian
2011-01-13  1:53 ` Corey Ashford
2011-01-13 13:20   ` Arnaldo Carvalho de Melo
2011-01-14  7:25 ` [tip:perf/urgent] perf sched: Fix list of events, dropping unsupported ':r' modifier tip-bot for Stephane Eranian
2011-08-03 10:59   ` Peter Zijlstra
2011-08-03 11:37     ` Frederic Weisbecker
2011-08-03 11:42       ` Peter Zijlstra
2011-08-03 11:57         ` Frederic Weisbecker
2011-08-03 12:05           ` Peter Zijlstra [this message]
2011-08-03 12:11             ` Frederic Weisbecker
2011-08-03 12:18               ` Peter Zijlstra
2011-08-03 17:06                 ` Arnaldo Carvalho de Melo
2011-08-03 19:49                   ` Peter Zijlstra

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=1312373135.1147.308.camel@twins \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=robert.richter@amd.com \
    --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