Hi, everyone:
      I wanna to ask  a question about libpfm4. In the perf_example directory, there are some examples about the use of libpfm4.  In the source code, the value must be scaled after the valued was read. It completed scaling by calling the function :perf_scale(). However, I can't understand why the readed PMU data should scaling.
And the returned Value, what's the mean of Value[0]. How can I get some documention about the read data format? Would you like to response me?
     On the other hand, I want to consult everyone a question about programming. In the application, there are two threads, one is main thread, the other is slice thread. I want to control some parameters in the slice thread by sampling the PMU events. When some condition is satisfied, then the slice thread must change its parameters. Some paper suggests piggyback  the slice thread, but I can't understand it. How about your suggestion?
   Looking forward to hear from you!
   Best regards!
Jason
2011/2/19



At 2011-02-18 02:19:48£¬perfmon2-devel-request@lists.sourceforge.net wrote: >Send perfmon2-devel mailing list submissions to > perfmon2-devel@lists.sourceforge.net > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >or, via email, send a message with subject or body 'help' to > perfmon2-devel-request@lists.sourceforge.net > >You can reach the person managing the list at > perfmon2-devel-owner@lists.sourceforge.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of perfmon2-devel digest..." > > >Today's Topics: > >   1. Re: [PATCH] Handle API changes for python (Arun Sharma) >   2. Re: [PATCH] Handle API changes for python (stephane eranian) >   3. [PATCH] perf: make perf stat print user provided full event >      names (Stephane Eranian) >   4. Re: [BUG] perf: perf report -n shows bogus number of samples >      (Arnaldo Carvalho de Melo) >   5. Re: [BUG] perf: perf report -n shows bogus number of samples >      (Stephane Eranian) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Tue, 15 Feb 2011 15:04:49 -0800 >From: Arun Sharma <asharma@fb.com> >Subject: Re: [perfmon2] [PATCH] Handle API changes for python >To: Stephane Eranian <eranian@google.com> >Cc: perfmon2-devel@lists.sourceforge.net >Message-ID: <20110215230449.GA22090@radium.snc4.facebook.com> >Content-Type: text/plain; charset=us-ascii > >On Tue, Feb 15, 2011 at 11:48:17PM +0100, Stephane Eranian wrote: >>  >> Why do you need to remove #if 0 code? > >I don't need to. Feel free to ignore that part of the patch :) > > -Arun > > > >------------------------------ > >Message: 2 >Date: Wed, 16 Feb 2011 10:18:13 +0100 >From: stephane eranian <eranian@googlemail.com> >Subject: Re: [perfmon2] [PATCH] Handle API changes for python >To: Arun Sharma <asharma@fb.com> >Cc: perfmon2-devel@lists.sourceforge.net, Stephane Eranian > <eranian@google.com> >Message-ID: > <AANLkTim0J=F7USYucXPrWcKOBg4NyDsvCc_D18JwfUMz@mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >Patch applied. >Thanks. > >On Wed, Feb 16, 2011 at 12:04 AM, Arun Sharma <asharma@fb.com> wrote: >> On Tue, Feb 15, 2011 at 11:48:17PM +0100, Stephane Eranian wrote: >>> >>> Why do you need to remove #if 0 code? >> >> I don't need to. Feel free to ignore that part of the patch :) >> >> ?-Arun >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> perfmon2-devel mailing list >> perfmon2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >> > > > >------------------------------ > >Message: 3 >Date: Wed, 16 Feb 2011 15:10:01 +0200 >From: Stephane Eranian <eranian@google.com> >Subject: [perfmon2] [PATCH] perf: make perf stat print user provided > full event names >To: linux-kernel@vger.kernel.org >Cc: perfmon2-devel@lists.sf.net, linux-perf-users@vger.kernel.org, > eranian@gmail.com, peterz@infradead.org, fweisbec@gmail.com, > eranian@google.com, acme@redhat.com, paulus@samba.org, mingo@elte.hu, > davem@davemloft.net >Message-ID: <4d5bdc64.98a1df0a.7aa3.06c2@mx.google.com> > >This patch changes the way perf stat prints event names at the end >of a run. Until now, it was trying to reconstruct the event name >from its encoding. The problem is that it would only print generic >events without their modifiers (u, k, pp). > >This patch saves the event name as passed by the user in the evsel >struct and uses it to print the final event name. > >This would also work in case perf is linked with a library (such as >libpfm4) which provides full PMU event tables. > >$ perf stat -e cycles:u,cycles:k date >Wed Feb 16 14:58:52 CET 2011 > > Performance counter stats for 'date': > >            568600 cycles:u                 >           2779715 cycles:k                 > >        0.001908182  seconds time elapsed > >Signed-off-by: Stephane Eranian <eranian@google.com> >--- > >diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c >index 211063e..5f1f364 100644 >--- a/tools/perf/util/evsel.c >+++ b/tools/perf/util/evsel.c >@@ -85,6 +85,7 @@ void perf_evsel__exit(struct perf_evsel *evsel) > void perf_evsel__delete(struct perf_evsel *evsel) > { >  perf_evsel__exit(evsel); >+ free(evsel->name); >  free(evsel); > } >  >diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h >index eecdc3a..c32b348 100644 >--- a/tools/perf/util/evsel.h >+++ b/tools/perf/util/evsel.h >@@ -45,6 +45,7 @@ struct perf_evsel { >  struct perf_counts *counts; >  int idx; >  void *priv; >+ char *name; > }; >  > struct cpu_map; >diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c >index cf082da..80a3dd5 100644 >--- a/tools/perf/util/parse-events.c >+++ b/tools/perf/util/parse-events.c >@@ -268,6 +268,9 @@ const char *event_name(struct perf_evsel *evsel) >  u64 config = evsel->attr.config; >  int type = evsel->attr.type; >  >+ if (evsel->name) >+ return evsel->name; >+ >  return __event_name(type, config); > } >  >@@ -782,8 +785,10 @@ int parse_events(const struct option *opt, const char *str, int unset __used) >  struct perf_evlist *evlist = *(struct perf_evlist **)opt->value; >  struct perf_event_attr attr; >  enum event_result ret; >+ const char *ostr; >  >  for (;;) { >+ ostr = str; >  memset(&attr, 0, sizeof(attr)); >  ret = parse_event_symbols(opt, &str, &attr); >  if (ret == EVT_FAILED) >@@ -798,6 +803,11 @@ int parse_events(const struct option *opt, const char *str, int unset __used) >  if (evsel == NULL) >  return -1; >  perf_evlist__add(evlist, evsel); >+ >+ evsel->name = calloc(str - ostr + 1, 1); >+ if (!evsel->name) >+ return -1; >+ strncpy(evsel->name, ostr, str - ostr); >  } >  >  if (*str == 0) > > > >------------------------------ > >Message: 4 >Date: Thu, 17 Feb 2011 13:23:13 -0200 >From: Arnaldo Carvalho de Melo <acme@redhat.com> >Subject: Re: [perfmon2] [BUG] perf: perf report -n shows bogus number > of samples >To: Stephane Eranian <eranian@google.com> >Cc: Peter Zijlstra <peterz@infradead.org>, Fr?d?ric Weisbecker > <fweisbec@gmail.com>, mingo@elte.hu, LKML > <linux-kernel@vger.kernel.org>, perfmon2-devel@lists.sf.net >Message-ID: <20110217152313.GD10805@ghostprotocols.net> >Content-Type: text/plain; charset=us-ascii > >Em Wed, Feb 09, 2011 at 12:34:44AM +0100, Stephane Eranian escreveu: >> I think the -n option of perf report shows bogus number of samples. >>  >> I believe it does not print the number of samples but rather the >> number of events if I understand the code in hist_entry__snprintf(). >> I think that's useless, the number of samples is more useful. > ><SNIP > >> $ perf record -e cycles ./repmov >> $ perf report -D | fgrep RECORD_SAMPLE | wc -l >> 86346 >> $ ./perf report -n >> # Events: 86K cycles >> # >> # Overhead  Samples    Command      Shared Object                     Symbol >> # ........ ..........  .......  .................  ......................... >> # >>     98.92%238206388334   repmov  repmov             [.] main >>      0.08%  189506224   repmov  [kernel.kallsyms]  [k] perf_ctx_adjust_freq >>      0.06%  147582706   repmov  [kernel.kallsyms]  [k] perf_event_task_tick >>  >> It should be easy to reproduce with any other program. > >Like this? Can I have your acked-by? > >commit 58e57f4dd6164bdbd5bc1f7d7c1ba5eb104e9b32 >Author: Arnaldo Carvalho de Melo <acme@redhat.com> >Date:   Thu Feb 17 10:37:23 2011 -0200 > >    perf hists: Print number of samples, not the period sum >     >    So that we match the header where we state the number of events with the >    "Samples" column when using 'perf report -n/--show-nr-samples': >     >     [root@emilia ~]# perf record -a sleep 1 >     [ perf record: Woken up 1 times to write data ] >     [ perf record: Captured and wrote 0.111 MB perf.data (~4860 samples) ] >     [root@emilia ~]# perf report --stdio --show-nr-samples >     # Events: 11  cycles >     # >     # Overhead  Samples        Command       Shared Object                        Symbol >     # ........ ..........  ...........  ..................  ............................ >     # >         16.65%          1        sleep  [kernel.kallsyms]   [k] unmap_vmas >         16.10%          1         perf  libpthread-2.12.so  [.] __pthread_cleanup_push_defer >         15.79%          2         perf  [kernel.kallsyms]   [k] format_decode >         12.88%          1  kworker/1:2  [kernel.kallsyms]   [k] cache_reap >         10.69%          1      swapper  [kernel.kallsyms]   [k] _raw_spin_lock >          7.55%          1        sleep  [kernel.kallsyms]   [k] prepare_exec_creds >          6.00%          1         perf  [jbd2]              [k] start_this_handle >          5.29%          1         perf  [kernel.kallsyms]   [k] seq_read >          4.75%          1         perf  [kernel.kallsyms]   [k] get_pid_task >          4.30%          1         perf  [kernel.kallsyms]   [k] _raw_spin_unlock_irqrestore >     >     # >     # (For a higher level overview, try: perf report --sort comm,dso) >     # >     [root@emilia ~]# >     >    Reported-by: Stephane Eranian <eranian@google.com> >    Cc: Frederic Weisbecker <fweisbec@gmail.com> >    Cc: Ingo Molnar <mingo@elte.hu> >    Cc: Mike Galbraith <efault@gmx.de> >    Cc: Paul Mackerras <paulus@samba.org> >    Cc: Peter Zijlstra <peterz@infradead.org> >    Cc: Stephane Eranian <eranian@google.com> >    Cc: Tom Zanussi <tzanussi@gmail.com> >    LKML-Reference: <new-submission> >    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> > >diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c >index 3f43723..da2899e 100644 >--- a/tools/perf/util/hist.c >+++ b/tools/perf/util/hist.c >@@ -591,6 +591,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, > { >  struct sort_entry *se; >  u64 period, total, period_sys, period_us, period_guest_sys, period_guest_us; >+ u64 nr_events; >  const char *sep = symbol_conf.field_sep; >  int ret; >  >@@ -599,6 +600,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >  >  if (pair_hists) { >  period = self->pair ? self->pair->period : 0; >+ nr_events = self->pair ? self->pair->nr_events : 0; >  total = pair_hists->stats.total_period; >  period_sys = self->pair ? self->pair->period_sys : 0; >  period_us = self->pair ? self->pair->period_us : 0; >@@ -606,6 +608,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >  period_guest_us = self->pair ? self->pair->period_guest_us : 0; >  } else { >  period = self->period; >+ nr_events = self->nr_events; >  total = session_total; >  period_sys = self->period_sys; >  period_us = self->period_us; >@@ -646,9 +649,9 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >  >  if (symbol_conf.show_nr_samples) { >  if (sep) >- ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, period); >+ ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, nr_events); >  else >- ret += snprintf(s + ret, size - ret, "%11" PRIu64, period); >+ ret += snprintf(s + ret, size - ret, "%11" PRIu64, nr_events); >  } >  >  if (pair_hists) { > > > >------------------------------ > >Message: 5 >Date: Thu, 17 Feb 2011 19:19:37 +0100 >From: Stephane Eranian <eranian@google.com> >Subject: Re: [perfmon2] [BUG] perf: perf report -n shows bogus number > of samples >To: Arnaldo Carvalho de Melo <acme@redhat.com> >Cc: Peter Zijlstra <peterz@infradead.org>, Fr?d?ric Weisbecker > <fweisbec@gmail.com>, mingo@elte.hu, LKML > <linux-kernel@vger.kernel.org>, perfmon2-devel@lists.sf.net >Message-ID: > <AANLkTi=Cbx7PdwPnL4QR1+GA37BQ63X5Cs_bW70yAwZJ@mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Thu, Feb 17, 2011 at 4:23 PM, Arnaldo Carvalho de Melo ><acme@redhat.com> wrote: >> Em Wed, Feb 09, 2011 at 12:34:44AM +0100, Stephane Eranian escreveu: >>> I think the -n option of perf report shows bogus number of samples. >>> >>> I believe it does not print the number of samples but rather the >>> number of events if I understand the code in hist_entry__snprintf(). >>> I think that's useless, the number of samples is more useful. >> >> <SNIP >> >>> $ perf record -e cycles ./repmov >>> $ perf report -D | fgrep RECORD_SAMPLE | wc -l >>> 86346 >>> $ ./perf report -n >>> # Events: 86K cycles >>> # >>> # Overhead ?Samples ? ?Command ? ? ?Shared Object ? ? ? ? ? ? ? ? ? ? Symbol >>> # ........ .......... ?....... ?................. ?......................... >>> # >>> ? ? 98.92%238206388334 ? repmov ?repmov ? ? ? ? ? ? [.] main >>> ? ? ?0.08% ?189506224 ? repmov ?[kernel.kallsyms] ?[k] perf_ctx_adjust_freq >>> ? ? ?0.06% ?147582706 ? repmov ?[kernel.kallsyms] ?[k] perf_event_task_tick >>> >>> It should be easy to reproduce with any other program. >> >> Like this? Can I have your acked-by? >> >Yes. Works for me. > >Acked-by: Stephane Eranian <eranian@google.com> > >> commit 58e57f4dd6164bdbd5bc1f7d7c1ba5eb104e9b32 >> Author: Arnaldo Carvalho de Melo <acme@redhat.com> >> Date: ? Thu Feb 17 10:37:23 2011 -0200 >> >> ? ?perf hists: Print number of samples, not the period sum >> >> ? ?So that we match the header where we state the number of events with the >> ? ?"Samples" column when using 'perf report -n/--show-nr-samples': >> >> ? ? [root@emilia ~]# perf record -a sleep 1 >> ? ? [ perf record: Woken up 1 times to write data ] >> ? ? [ perf record: Captured and wrote 0.111 MB perf.data (~4860 samples) ] >> ? ? [root@emilia ~]# perf report --stdio --show-nr-samples >> ? ? # Events: 11 ?cycles >> ? ? # >> ? ? # Overhead ?Samples ? ? ? ?Command ? ? ? Shared Object ? ? ? ? ? ? ? ? ? ? ? ?Symbol >> ? ? # ........ .......... ?........... ?.................. ?............................ >> ? ? # >> ? ? ? ? 16.65% ? ? ? ? ?1 ? ? ? ?sleep ?[kernel.kallsyms] ? [k] unmap_vmas >> ? ? ? ? 16.10% ? ? ? ? ?1 ? ? ? ? perf ?libpthread-2.12.so ?[.] __pthread_cleanup_push_defer >> ? ? ? ? 15.79% ? ? ? ? ?2 ? ? ? ? perf ?[kernel.kallsyms] ? [k] format_decode >> ? ? ? ? 12.88% ? ? ? ? ?1 ?kworker/1:2 ?[kernel.kallsyms] ? [k] cache_reap >> ? ? ? ? 10.69% ? ? ? ? ?1 ? ? ?swapper ?[kernel.kallsyms] ? [k] _raw_spin_lock >> ? ? ? ? ?7.55% ? ? ? ? ?1 ? ? ? ?sleep ?[kernel.kallsyms] ? [k] prepare_exec_creds >> ? ? ? ? ?6.00% ? ? ? ? ?1 ? ? ? ? perf ?[jbd2] ? ? ? ? ? ? ?[k] start_this_handle >> ? ? ? ? ?5.29% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] seq_read >> ? ? ? ? ?4.75% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] get_pid_task >> ? ? ? ? ?4.30% ? ? ? ? ?1 ? ? ? ? perf ?[kernel.kallsyms] ? [k] _raw_spin_unlock_irqrestore >> >> ? ? # >> ? ? # (For a higher level overview, try: perf report --sort comm,dso) >> ? ? # >> ? ? [root@emilia ~]# >> >> ? ?Reported-by: Stephane Eranian <eranian@google.com> >> ? ?Cc: Frederic Weisbecker <fweisbec@gmail.com> >> ? ?Cc: Ingo Molnar <mingo@elte.hu> >> ? ?Cc: Mike Galbraith <efault@gmx.de> >> ? ?Cc: Paul Mackerras <paulus@samba.org> >> ? ?Cc: Peter Zijlstra <peterz@infradead.org> >> ? ?Cc: Stephane Eranian <eranian@google.com> >> ? ?Cc: Tom Zanussi <tzanussi@gmail.com> >> ? ?LKML-Reference: <new-submission> >> ? ?Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> >> >> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c >> index 3f43723..da2899e 100644 >> --- a/tools/perf/util/hist.c >> +++ b/tools/perf/util/hist.c >> @@ -591,6 +591,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> ?{ >> ? ? ? ?struct sort_entry *se; >> ? ? ? ?u64 period, total, period_sys, period_us, period_guest_sys, period_guest_us; >> + ? ? ? u64 nr_events; >> ? ? ? ?const char *sep = symbol_conf.field_sep; >> ? ? ? ?int ret; >> >> @@ -599,6 +600,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> >> ? ? ? ?if (pair_hists) { >> ? ? ? ? ? ? ? ?period = self->pair ? self->pair->period : 0; >> + ? ? ? ? ? ? ? nr_events = self->pair ? self->pair->nr_events : 0; >> ? ? ? ? ? ? ? ?total = pair_hists->stats.total_period; >> ? ? ? ? ? ? ? ?period_sys = self->pair ? self->pair->period_sys : 0; >> ? ? ? ? ? ? ? ?period_us = self->pair ? self->pair->period_us : 0; >> @@ -606,6 +608,7 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> ? ? ? ? ? ? ? ?period_guest_us = self->pair ? self->pair->period_guest_us : 0; >> ? ? ? ?} else { >> ? ? ? ? ? ? ? ?period = self->period; >> + ? ? ? ? ? ? ? nr_events = self->nr_events; >> ? ? ? ? ? ? ? ?total = session_total; >> ? ? ? ? ? ? ? ?period_sys = self->period_sys; >> ? ? ? ? ? ? ? ?period_us = self->period_us; >> @@ -646,9 +649,9 @@ int hist_entry__snprintf(struct hist_entry *self, char *s, size_t size, >> >> ? ? ? ?if (symbol_conf.show_nr_samples) { >> ? ? ? ? ? ? ? ?if (sep) >> - ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, period); >> + ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%c%" PRIu64, *sep, nr_events); >> ? ? ? ? ? ? ? ?else >> - ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%11" PRIu64, period); >> + ? ? ? ? ? ? ? ? ? ? ? ret += snprintf(s + ret, size - ret, "%11" PRIu64, nr_events); >> ? ? ? ?} >> >> ? ? ? ?if (pair_hists) { >> > > > >------------------------------ > >------------------------------------------------------------------------------ >The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >Pinpoint memory and threading errors before they happen. >Find and fix more than 250 security defects in the development cycle. >Locate bottlenecks in serial and parallel code that limit performance. >http://p.sf.net/sfu/intel-dev2devfeb > >------------------------------ > >_______________________________________________ >perfmon2-devel mailing list >perfmon2-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/perfmon2-devel > > >End of perfmon2-devel Digest, Vol 40, Issue 15 >**********************************************