mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	David Ahern <dsahern@gmail.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Andi Kleen <ak@linux.intel.com>,
	Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH 4/9] perf stat: Remove transaction_run from shadow update/print code
Date: Wed, 3 Jun 2015 12:55:43 -0300	[thread overview]
Message-ID: <20150603155543.GA32707@kernel.org> (raw)
In-Reply-To: <20150603151450.GA1246@krava.redhat.com>

Em Wed, Jun 03, 2015 at 05:14:50PM +0200, Jiri Olsa escreveu:
> On Wed, Jun 03, 2015 at 12:10:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jun 03, 2015 at 04:25:54PM +0200, Jiri Olsa escreveu:
> > > It's no longer needed, because we use nameid to recognize
> > > transaction events.
> > > 
> > > Keeping it only in stat code to initialize transaction events.
> > 
> > Lemme see if I understand this correctly, this update_shadow_stats() is
> > called only for transaction runs?
> > 
> > It doesn't seem so, so now we will update those stats all the time?
> 
> update_shadow_stats is called on currently read/processed
> counter and based on its 'type' we update various other
> counters - shadow counters - which are the base for things
> like IPC in the stat output


So:

-       else if (transaction_run && perf_stat_evsel__is(counter, CYCLES_IN_TX))
+       else if (perf_stat_evsel__is(counter, CYCLES_IN_TX))
                update_stats(&runtime_transaction_stats[ctx][cpu], count[0]);


Before we were going to check this _only_ when transaction_run was set,
now we are doing it always, or are you saying that
perf_stat_evsel__is(counter, CYCLES_IN_TX) will only return true for
transaction 'perf stat' usage?

Let me take a look:

Yes, in all cases we, start doing:

   perf_evlist__alloc_stats()
     perf_evsel__alloc_stat_priv()
       perf_evsel__reset_stat_priv()
         perf_stat_evsel_id_init();
           struct perf_stat *ps = evsel->priv;
           ps->id = one of the entries below:

static const char *id_str[PERF_STAT_EVSEL_ID__MAX] = {
        ID(NONE,                x),
        ID(CYCLES_IN_TX,        cpu/cycles-t/),
        ID(TRANSACTION_START,   cpu/tx-start/),
        ID(ELISION_START,       cpu/el-start/),
        ID(CYCLES_IN_TX_CP,     cpu/cycles-ct/),
};


Ok, guess I understood now, all the events above are transaction events,
so if one of them is present, then, yes, this is a transaction run, and
we don't need to look at the 'transaction_run' variable to update the
shadow stats, got it right?

I.e. we _never_ needed to look at 'transaction_id', just noticing that
ps->id is not zero, ok.

- Arnaldo

  reply	other threads:[~2015-06-03 15:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-03 14:25 [PATCHv2 0/9] perf stat: Separate shadow counters code Jiri Olsa
2015-06-03 14:25 ` [PATCH 1/9] perf stat: Add id into perf_stat struct Jiri Olsa
2015-06-04 13:50   ` [PATCHv3] " Jiri Olsa
2015-06-08 14:03     ` Arnaldo Carvalho de Melo
2015-06-09 20:09       ` Jiri Olsa
2015-06-09  9:48     ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 2/9] perf stat: Replace transaction event possition check with id check Jiri Olsa
2015-06-09  9:49   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 3/9] perf stat: Remove setup_events function Jiri Olsa
2015-06-09  9:49   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 4/9] perf stat: Remove transaction_run from shadow update/print code Jiri Olsa
2015-06-03 15:10   ` Arnaldo Carvalho de Melo
2015-06-03 15:14     ` Jiri Olsa
2015-06-03 15:55       ` Arnaldo Carvalho de Melo [this message]
2015-06-09  9:49   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 5/9] perf stat: Introduce reset_shadow_stats function Jiri Olsa
2015-06-09  9:50   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 6/9] perf stat: Introduce print_shadow_stats function Jiri Olsa
2015-06-09  9:50   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 7/9] perf stat: Add output file argument to " Jiri Olsa
2015-06-09  9:50   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 8/9] perf stat: Add aggr_mode " Jiri Olsa
2015-06-09  9:51   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 14:25 ` [PATCH 9/9] perf stat: Move shadow stat counters into separate object Jiri Olsa
2015-06-09  9:51   ` [tip:perf/core] " tip-bot for Jiri Olsa
2015-06-03 22:07 ` [PATCHv2 0/9] perf stat: Separate shadow counters code Arnaldo Carvalho de Melo
2015-06-03 22:24   ` Arnaldo Carvalho de Melo
2015-06-03 22:38     ` Jiri Olsa
2015-06-03 22:42       ` Arnaldo Carvalho de Melo
2015-06-04 13:49         ` Jiri Olsa
  -- strict thread matches above, loose matches on Subject: below --
2015-06-01 22:59 [PATCH " Jiri Olsa
2015-06-01 22:59 ` [PATCH 4/9] perf stat: Remove transaction_run from shadow update/print code Jiri Olsa

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=20150603155543.GA32707@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ak@linux.intel.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@google.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=paulus@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome