Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1275923 > unrolled thread

[GIT PULL 0/7] perf/core improvements and fixes

Started byArnaldo Carvalho de Melo <acme@kernel.org>
First post2015-11-23 23:10 +0100
Last post2015-11-26 09:20 +0100
Articles 12 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [GIT PULL 0/7] perf/core improvements and fixes Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-11-23 23:10 +0100
    Re: [GIT PULL 0/7] perf/core improvements and fixes Ingo Molnar <mingo@kernel.org> - 2015-11-24 09:20 +0100
      Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-24 09:30 +0100
        Re: [GIT PULL 0/7] perf/core improvements and fixes Ingo Molnar <mingo@kernel.org> - 2015-11-24 09:50 +0100
          Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-24 10:30 +0100
            Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-24 10:50 +0100
              Re: [GIT PULL 0/7] perf/core improvements and fixes Ingo Molnar <mingo@kernel.org> - 2015-11-26 12:10 +0100
                Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-26 13:50 +0100
            Re: [GIT PULL 0/7] perf/core improvements and fixes Ingo Molnar <mingo@kernel.org> - 2015-11-26 09:00 +0100
              Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-26 10:10 +0100
      Re: [GIT PULL 0/7] perf/core improvements and fixes Jiri Olsa <jolsa@redhat.com> - 2015-11-24 11:30 +0100
      Re: [GIT PULL 0/7] perf/core improvements and fixes Ingo Molnar <mingo@kernel.org> - 2015-11-26 09:20 +0100

#1275923 — [GIT PULL 0/7] perf/core improvements and fixes

FromArnaldo Carvalho de Melo <acme@kernel.org>
Date2015-11-23 23:10 +0100
Subject[GIT PULL 0/7] perf/core improvements and fixes
Message-ID<qy7jr-7vZ-5@gated-at.bofh.it>
Hi Ingo,

	Please consider pulling,

- Arnaldo


The following changes since commit b7883a1c4f75edb62fc49da6000c59fb881e3c7b:

  perf/x86: Handle multiple umask bits for BDW CYCLE_ACTIVITY.* (2015-11-23 09:58:27 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo

for you to fetch changes up to 646a6e846c4dc3812c614fd061603b6db5b8d380:

  perf callchain: Add missing parent_val initialization (2015-11-23 18:31:25 -0300)

----------------------------------------------------------------
perf/core improvements and fixes:

User visible:

- Allow callchain order (caller, callee) to the libdw and libunwind based DWARF
  unwinders (Jiri Olsa)

- Add missing parent_val initialization in the callchain code, fixing a
  SEGFAULT when using callchains with 'perf top' (Jiri Olsa)

- Add initial 'perf config' command, for now just with a --list command to
  show the contents of the configuration file in use and a basic man page
  describing its format, commands for doing edits and detailed documentation
  are being reviewed and proof-read. (Taeung Song)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

----------------------------------------------------------------
Jiri Olsa (5):
      perf callchain: Move initial entry call into get_entries function
      perf callchain: Add order support for libunwind DWARF unwinder
      perf test: Add callchain order setup for DWARF unwinder test
      perf callchain: Add order support for libdw DWARF unwinder
      perf callchain: Add missing parent_val initialization

Taeung Song (2):
      perf tools: Add 'perf config' command
      perf config: Add initial man page

 tools/perf/Build                         |   1 +
 tools/perf/Documentation/perf-config.txt | 103 +++++++++++++++++++++++++++++++
 tools/perf/builtin-config.c              |  66 ++++++++++++++++++++
 tools/perf/builtin.h                     |   1 +
 tools/perf/command-list.txt              |   1 +
 tools/perf/perf.c                        |   1 +
 tools/perf/tests/dwarf-unwind.c          |  22 ++++++-
 tools/perf/util/callchain.h              |   1 +
 tools/perf/util/unwind-libdw.c           |  53 +++++++++++-----
 tools/perf/util/unwind-libdw.h           |   2 +
 tools/perf/util/unwind-libunwind.c       |  60 +++++++++++-------
 11 files changed, 272 insertions(+), 39 deletions(-)
 create mode 100644 tools/perf/Documentation/perf-config.txt
 create mode 100644 tools/perf/builtin-config.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1276143

FromIngo Molnar <mingo@kernel.org>
Date2015-11-24 09:20 +0100
Message-ID<qygZs-5z4-7@gated-at.bofh.it>
In reply to#1275923
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Hi Ingo,
> 
> 	Please consider pulling,
> 
> - Arnaldo
> 
> 
> The following changes since commit b7883a1c4f75edb62fc49da6000c59fb881e3c7b:
> 
>   perf/x86: Handle multiple umask bits for BDW CYCLE_ACTIVITY.* (2015-11-23 09:58:27 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo
> 
> for you to fetch changes up to 646a6e846c4dc3812c614fd061603b6db5b8d380:
> 
>   perf callchain: Add missing parent_val initialization (2015-11-23 18:31:25 -0300)
> 
> ----------------------------------------------------------------
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Allow callchain order (caller, callee) to the libdw and libunwind based DWARF
>   unwinders (Jiri Olsa)
> 
> - Add missing parent_val initialization in the callchain code, fixing a
>   SEGFAULT when using callchains with 'perf top' (Jiri Olsa)
> 
> - Add initial 'perf config' command, for now just with a --list command to
>   show the contents of the configuration file in use and a basic man page
>   describing its format, commands for doing edits and detailed documentation
>   are being reviewed and proof-read. (Taeung Song)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> ----------------------------------------------------------------
> Jiri Olsa (5):
>       perf callchain: Move initial entry call into get_entries function
>       perf callchain: Add order support for libunwind DWARF unwinder
>       perf test: Add callchain order setup for DWARF unwinder test
>       perf callchain: Add order support for libdw DWARF unwinder
>       perf callchain: Add missing parent_val initialization
> 
> Taeung Song (2):
>       perf tools: Add 'perf config' command
>       perf config: Add initial man page
> 
>  tools/perf/Build                         |   1 +
>  tools/perf/Documentation/perf-config.txt | 103 +++++++++++++++++++++++++++++++
>  tools/perf/builtin-config.c              |  66 ++++++++++++++++++++
>  tools/perf/builtin.h                     |   1 +
>  tools/perf/command-list.txt              |   1 +
>  tools/perf/perf.c                        |   1 +
>  tools/perf/tests/dwarf-unwind.c          |  22 ++++++-
>  tools/perf/util/callchain.h              |   1 +
>  tools/perf/util/unwind-libdw.c           |  53 +++++++++++-----
>  tools/perf/util/unwind-libdw.h           |   2 +
>  tools/perf/util/unwind-libunwind.c       |  60 +++++++++++-------
>  11 files changed, 272 insertions(+), 39 deletions(-)
>  create mode 100644 tools/perf/Documentation/perf-config.txt
>  create mode 100644 tools/perf/builtin-config.c

Hm, I noticed something weird - I think it started with this pull request - the 
feature detection build messages come mixed with the regular build:

triton:~/tip/tools/perf> make
  BUILD:   Doing 'make -j12' parallel build

Auto-detecting system features:
...                         dwarf: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ on  ]
...                      libaudit: [ on  ]
...                        libbfd: [ on  ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ on  ]
...                     libpython: [ on  ]
...                      libslang: [ on  ]
...                     libunwind: [ on  ]
...            libdw-dwarf-unwind: [ on  ]
...                          zlib: [ on  ]
...                          lzma: [ on  ]
...                     get_cpuid: [ on  ]
...                           bpf: [ on  ]

  GEN      common-cmds.h
  CC       perf-read-vdso32
  CC       perf-read-vdsox32
  CC       ui/gtk/browser.o
  CC       ui/gtk/hists.o
  CC       ui/gtk/setup.o
  CC       ui/gtk/util.o
  CC       ui/gtk/helpline.o
  CC       ui/gtk/progress.o
  CC       ui/gtk/annotate.o
  CC       util/abspath.o
  CC       fd/array.o

Auto-detecting system features:
  CC       event-parse.o
...                        libelf: [ on  ]
  PERF_VERSION = 4.4.rc2.g9327ca
...                           bpf: [ on  ]

  CC       util/alias.o
  CC       libbpf.o


while normally we'd first do feature detection, then only do the build (knowing 
which features to build).

Occasionally it also triggers a build failure:

  CC       plugin_kvm.o
  CC       arch/common.o
  CC       util/db-export.o
  LD       plugin_kmem-in.o
fixdep: error opening depfile: ./.plugin_kmem.o.d: No such file or directory
/home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_kmem.o' 
failed
make[3]: *** [plugin_kmem.o] Error 2
Makefile:189: recipe for target 'plugin_kmem-in.o' failed
make[2]: *** [plugin_kmem-in.o] Error 2
Makefile.perf:424: recipe for target 'install-traceevent-plugins' failed
make[1]: *** [install-traceevent-plugins] Error 2
make[1]: *** Waiting for unfinished jobs....

that too seems to be a result of unwanted, over-eager parallelism.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276156

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-24 09:30 +0100
Message-ID<qyh98-5D3-13@gated-at.bofh.it>
In reply to#1276143
On Tue, Nov 24, 2015 at 09:10:42AM +0100, Ingo Molnar wrote:

SNIP

> 
>   GEN      common-cmds.h
>   CC       perf-read-vdso32
>   CC       perf-read-vdsox32
>   CC       ui/gtk/browser.o
>   CC       ui/gtk/hists.o
>   CC       ui/gtk/setup.o
>   CC       ui/gtk/util.o
>   CC       ui/gtk/helpline.o
>   CC       ui/gtk/progress.o
>   CC       ui/gtk/annotate.o
>   CC       util/abspath.o
>   CC       fd/array.o
> 
> Auto-detecting system features:
>   CC       event-parse.o
> ...                        libelf: [ on  ]
>   PERF_VERSION = 4.4.rc2.g9327ca
> ...                           bpf: [ on  ]
> 
>   CC       util/alias.o
>   CC       libbpf.o
> 
> 
> while normally we'd first do feature detection, then only do the build (knowing 
> which features to build).

the bpf lib is doing its own feature detection, to be able
to stand alone.. I'll see if we could share detected features
somehow, so sub builds don't need to do that

> 
> Occasionally it also triggers a build failure:
> 
>   CC       plugin_kvm.o
>   CC       arch/common.o
>   CC       util/db-export.o
>   LD       plugin_kmem-in.o
> fixdep: error opening depfile: ./.plugin_kmem.o.d: No such file or directory
> /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_kmem.o' 
> failed
> make[3]: *** [plugin_kmem.o] Error 2
> Makefile:189: recipe for target 'plugin_kmem-in.o' failed
> make[2]: *** [plugin_kmem-in.o] Error 2
> Makefile.perf:424: recipe for target 'install-traceevent-plugins' failed
> make[1]: *** [install-traceevent-plugins] Error 2
> make[1]: *** Waiting for unfinished jobs....
> 
> that too seems to be a result of unwanted, over-eager parallelism.

hm, haven't seen that one for long time now ;-) will check

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276165

FromIngo Molnar <mingo@kernel.org>
Date2015-11-24 09:50 +0100
Message-ID<qyhsu-5Kj-11@gated-at.bofh.it>
In reply to#1276156
* Jiri Olsa <jolsa@redhat.com> wrote:

> On Tue, Nov 24, 2015 at 09:10:42AM +0100, Ingo Molnar wrote:
> 
> SNIP
> 
> > 
> >   GEN      common-cmds.h
> >   CC       perf-read-vdso32
> >   CC       perf-read-vdsox32
> >   CC       ui/gtk/browser.o
> >   CC       ui/gtk/hists.o
> >   CC       ui/gtk/setup.o
> >   CC       ui/gtk/util.o
> >   CC       ui/gtk/helpline.o
> >   CC       ui/gtk/progress.o
> >   CC       ui/gtk/annotate.o
> >   CC       util/abspath.o
> >   CC       fd/array.o
> > 
> > Auto-detecting system features:
> >   CC       event-parse.o
> > ...                        libelf: [ on  ]
> >   PERF_VERSION = 4.4.rc2.g9327ca
> > ...                           bpf: [ on  ]
> > 
> >   CC       util/alias.o
> >   CC       libbpf.o
> > 
> > 
> > while normally we'd first do feature detection, then only do the build (knowing 
> > which features to build).
> 
> the bpf lib is doing its own feature detection, to be able
> to stand alone.. I'll see if we could share detected features
> somehow, so sub builds don't need to do that
> 
> > 
> > Occasionally it also triggers a build failure:
> > 
> >   CC       plugin_kvm.o
> >   CC       arch/common.o
> >   CC       util/db-export.o
> >   LD       plugin_kmem-in.o
> > fixdep: error opening depfile: ./.plugin_kmem.o.d: No such file or directory
> > /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_kmem.o' 
> > failed
> > make[3]: *** [plugin_kmem.o] Error 2
> > Makefile:189: recipe for target 'plugin_kmem-in.o' failed
> > make[2]: *** [plugin_kmem-in.o] Error 2
> > Makefile.perf:424: recipe for target 'install-traceevent-plugins' failed
> > make[1]: *** [install-traceevent-plugins] Error 2
> > make[1]: *** Waiting for unfinished jobs....
> > 
> > that too seems to be a result of unwanted, over-eager parallelism.
> 
> hm, haven't seen that one for long time now ;-) will check

So maybe that's a side effect, because I do:

  make clean install

and maybe 'clean' happens in parallel with 'install'?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276189

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-24 10:30 +0100
Message-ID<qyi5c-6fp-15@gated-at.bofh.it>
In reply to#1276165
On Tue, Nov 24, 2015 at 09:42:10AM +0100, Ingo Molnar wrote:

SNIP

> > 
> > > 
> > > Occasionally it also triggers a build failure:
> > > 
> > >   CC       plugin_kvm.o
> > >   CC       arch/common.o
> > >   CC       util/db-export.o
> > >   LD       plugin_kmem-in.o
> > > fixdep: error opening depfile: ./.plugin_kmem.o.d: No such file or directory
> > > /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_kmem.o' 
> > > failed
> > > make[3]: *** [plugin_kmem.o] Error 2
> > > Makefile:189: recipe for target 'plugin_kmem-in.o' failed
> > > make[2]: *** [plugin_kmem-in.o] Error 2
> > > Makefile.perf:424: recipe for target 'install-traceevent-plugins' failed
> > > make[1]: *** [install-traceevent-plugins] Error 2
> > > make[1]: *** Waiting for unfinished jobs....
> > > 
> > > that too seems to be a result of unwanted, over-eager parallelism.
> > 
> > hm, haven't seen that one for long time now ;-) will check
> 
> So maybe that's a side effect, because I do:
> 
>   make clean install
> 
> and maybe 'clean' happens in parallel with 'install'?

the fixdep error indicates that it was invoked after building object
plugin_kmem-in.o, but it could not find its dep file (.plugin_kmem-in.o.d)
which is built within the object build.. so seems like race with clean
or other build of the same object

however ;-)

The 'Makefile' processing itself isn't paralel and will exec
clean and install targets serialized:

---
[root@intel-wildcatpass-07 perf]# make clean install
make -f Makefile.perf --no-print-directory -j88 O=  clean
  CLEAN    libtraceevent
  CLEAN    libapi
  CLEAN    libbpf
  CLEAN    config
  CLEAN    core-objs
  CLEAN    core-progs
  CLEAN    core-gen
  SUBDIR   Documentation
  CLEAN    Documentation
  CLEAN    python
  BUILD:   Doing 'make -j88' parallel build
make -f Makefile.perf --no-print-directory -j88 O=  install

Auto-detecting system features:
...                         dwarf: [ on  ]
...                         glibc: [ on  ]
---

I can't make that failure on 88 cpus server, I assume you can
reproduce this fairly easily?

Could you please share failing build output from:
  $ make V=1 clean install

thanks,
jirka

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276240

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-24 10:50 +0100
Message-ID<qyioz-6mU-35@gated-at.bofh.it>
In reply to#1276189
On Tue, Nov 24, 2015 at 10:26:18AM +0100, Jiri Olsa wrote:
> On Tue, Nov 24, 2015 at 09:42:10AM +0100, Ingo Molnar wrote:
> 
> SNIP
> 
> > > 
> > > > 
> > > > Occasionally it also triggers a build failure:
> > > > 
> > > >   CC       plugin_kvm.o
> > > >   CC       arch/common.o
> > > >   CC       util/db-export.o
> > > >   LD       plugin_kmem-in.o
> > > > fixdep: error opening depfile: ./.plugin_kmem.o.d: No such file or directory
> > > > /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_kmem.o' 
> > > > failed
> > > > make[3]: *** [plugin_kmem.o] Error 2
> > > > Makefile:189: recipe for target 'plugin_kmem-in.o' failed
> > > > make[2]: *** [plugin_kmem-in.o] Error 2
> > > > Makefile.perf:424: recipe for target 'install-traceevent-plugins' failed
> > > > make[1]: *** [install-traceevent-plugins] Error 2
> > > > make[1]: *** Waiting for unfinished jobs....
> > > > 
> > > > that too seems to be a result of unwanted, over-eager parallelism.
> > > 
> > > hm, haven't seen that one for long time now ;-) will check
> > 
> > So maybe that's a side effect, because I do:
> > 
> >   make clean install
> > 
> > and maybe 'clean' happens in parallel with 'install'?
> 
> the fixdep error indicates that it was invoked after building object
> plugin_kmem-in.o, but it could not find its dep file (.plugin_kmem-in.o.d)
> which is built within the object build.. so seems like race with clean
> or other build of the same object
> 
> however ;-)
> 
> The 'Makefile' processing itself isn't paralel and will exec
> clean and install targets serialized:
> 
> ---
> [root@intel-wildcatpass-07 perf]# make clean install
> make -f Makefile.perf --no-print-directory -j88 O=  clean
>   CLEAN    libtraceevent
>   CLEAN    libapi
>   CLEAN    libbpf
>   CLEAN    config
>   CLEAN    core-objs
>   CLEAN    core-progs
>   CLEAN    core-gen
>   SUBDIR   Documentation
>   CLEAN    Documentation
>   CLEAN    python
>   BUILD:   Doing 'make -j88' parallel build
> make -f Makefile.perf --no-print-directory -j88 O=  install
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...                         glibc: [ on  ]
> ---
> 
> I can't make that failure on 88 cpus server, I assume you can
> reproduce this fairly easily?
> 
> Could you please share failing build output from:
>   $ make V=1 clean install
> 
> thanks,
> jirka
> 

I think I found one race..
 - having install-traceevent-plugins depend on $(LIBTRACEEVENT),
   plugins will not be built as its prereq. and the target
   install-traceevent-plugins itself will trigger plugins build
 - but plugins build is also triggered by perf build itself
   via libtraceevent_plugins target

so those 2 might race.. but as I said, I've never reproduced ;-)

Could you please give it a try?

thanks,
jirka


---
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 0d19d5447d6c..929a32ba15f5 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -420,7 +420,7 @@ $(LIBTRACEEVENT)-clean:
 	$(call QUIET_CLEAN, libtraceevent)
 	$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null
 
-install-traceevent-plugins: $(LIBTRACEEVENT)
+install-traceevent-plugins: libtraceevent_plugins
 	$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) install_plugins
 
 $(LIBAPI): fixdep FORCE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278149

FromIngo Molnar <mingo@kernel.org>
Date2015-11-26 12:10 +0100
Message-ID<qz2B3-4lj-5@gated-at.bofh.it>
In reply to#1276240
* Jiri Olsa <jolsa@redhat.com> wrote:

> I think I found one race..
>  - having install-traceevent-plugins depend on $(LIBTRACEEVENT),
>    plugins will not be built as its prereq. and the target
>    install-traceevent-plugins itself will trigger plugins build
>  - but plugins build is also triggered by perf build itself
>    via libtraceevent_plugins target
> 
> so those 2 might race.. but as I said, I've never reproduced ;-)
> 
> Could you please give it a try?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 0d19d5447d6c..929a32ba15f5 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -420,7 +420,7 @@ $(LIBTRACEEVENT)-clean:
>  	$(call QUIET_CLEAN, libtraceevent)
>  	$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null
>  
> -install-traceevent-plugins: $(LIBTRACEEVENT)
> +install-traceevent-plugins: libtraceevent_plugins
>  	$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) install_plugins
>  

Ok, so I tried this fix with my 'sleep 1' hack to make the race easier to trigger, 
and without your fix it still fails fairly quickly:

triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install V=1 >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
Thu Nov 26 11:54:36 CET 2015 pass
Thu Nov 26 11:54:47 CET 2015 FAIL!

but with your fix applied it passes a reasonable number of builds:

triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install V=1 >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
Thu Nov 26 11:55:12 CET 2015 pass
Thu Nov 26 11:55:25 CET 2015 pass
Thu Nov 26 11:55:36 CET 2015 pass
Thu Nov 26 11:55:47 CET 2015 pass
Thu Nov 26 11:55:58 CET 2015 pass
Thu Nov 26 11:56:09 CET 2015 pass
Thu Nov 26 11:56:21 CET 2015 pass
Thu Nov 26 11:56:32 CET 2015 pass
Thu Nov 26 11:56:44 CET 2015 pass
Thu Nov 26 11:56:55 CET 2015 pass
Thu Nov 26 11:57:06 CET 2015 pass
Thu Nov 26 11:57:18 CET 2015 pass
Thu Nov 26 11:57:29 CET 2015 pass
Thu Nov 26 11:57:40 CET 2015 pass
Thu Nov 26 11:57:51 CET 2015 pass
Thu Nov 26 11:58:03 CET 2015 pass

So I think the bug is fixed for good:

  Tested-by: Ingo Molnar <mingo@kernel.org>

( I'll keep it running some longer and will let you know if there's any failure.
  Consider it fixed if I don't send any update. )

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278192

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-26 13:50 +0100
Message-ID<qz49R-5c7-29@gated-at.bofh.it>
In reply to#1278149
On Thu, Nov 26, 2015 at 12:00:00PM +0100, Ingo Molnar wrote:

SNIP

> Thu Nov 26 11:55:58 CET 2015 pass
> Thu Nov 26 11:56:09 CET 2015 pass
> Thu Nov 26 11:56:21 CET 2015 pass
> Thu Nov 26 11:56:32 CET 2015 pass
> Thu Nov 26 11:56:44 CET 2015 pass
> Thu Nov 26 11:56:55 CET 2015 pass
> Thu Nov 26 11:57:06 CET 2015 pass
> Thu Nov 26 11:57:18 CET 2015 pass
> Thu Nov 26 11:57:29 CET 2015 pass
> Thu Nov 26 11:57:40 CET 2015 pass
> Thu Nov 26 11:57:51 CET 2015 pass
> Thu Nov 26 11:58:03 CET 2015 pass
> 
> So I think the bug is fixed for good:
> 
>   Tested-by: Ingo Molnar <mingo@kernel.org>
> 
> ( I'll keep it running some longer and will let you know if there's any failure.
>   Consider it fixed if I don't send any update. )

I wonder what's different in your setup, because I still
cannot hit that.. anyway, thanks ;-) I'll send out full patch

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278038

FromIngo Molnar <mingo@kernel.org>
Date2015-11-26 09:00 +0100
Message-ID<qyZDc-1YS-7@gated-at.bofh.it>
In reply to#1276189
* Jiri Olsa <jolsa@redhat.com> wrote:

> I can't make that failure on 88 cpus server, I assume you can
> reproduce this fairly easily?

Yeah, when it triggers it reproduces fairly easily - but it seems to be dependent 
on build timings. I don't use a large server for this test, just a single socket 
system with 6 cores / 12 CPUs.

> Could you please share failing build output from:
>   $ make V=1 clean install

The problem went away after I unpulled - I'll pull it again and will try to get 
you debug output.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278097

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-26 10:10 +0100
Message-ID<qz0IV-35e-9@gated-at.bofh.it>
In reply to#1278038
On Thu, Nov 26, 2015 at 09:12:37AM +0100, Ingo Molnar wrote:

SNIP

> fixdep: error opening depfile: ./.plugin_hrtimer.o.d: No such file or directory
> /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 
> 'plugin_hrtimer.o' failed
> make[3]: *** [plugin_hrtimer.o] Error 2
> Makefile:189: recipe for target 'plugin_hrtimer-in.o' failed
> make[2]: *** [plugin_hrtimer-in.o] Error 2
> Makefile.perf:414: recipe for target 'libtraceevent_plugins' failed
> make[1]: *** [libtraceevent_plugins] Error 2
> make[1]: *** Waiting for unfinished jobs....
>   CC       plugin_kvm.o
>   CC       builtin-sched.o
>   CC       plugin_mac80211.o
>   LD       plugin_kmem-in.o
>   CC       util/help.o
> 
> Can you reproduce it by adding 'sleep 1' (or 'sleep 2') to the end of 
> util/PERF-VERSION-GEN? (See the patch attached further below.)
> 
> The failure is sporadic even with the 'sleep 1' hack - I get a build failure 1 out 
> of 3 times maybe:
> 
> triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
> Thu Nov 26 09:07:12 CET 2015 pass
> Thu Nov 26 09:07:23 CET 2015 FAIL!
> 
> Interestingly it does not reproduce if I use '>FAIL.log' - I need to output the 
> log into tmpfs - maybe the extra VFS synchronization if logging to the same 
> filesystem where the build occurs hides the race?
> 
> With V=1 it takes a lot longer to reproduce:
> 
> triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install V=1 >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
> Thu Nov 26 09:08:08 CET 2015 pass
> Thu Nov 26 09:08:20 CET 2015 pass
> Thu Nov 26 09:08:32 CET 2015 pass
> Thu Nov 26 09:08:43 CET 2015 pass
> Thu Nov 26 09:08:55 CET 2015 pass
> Thu Nov 26 09:09:06 CET 2015 pass
> Thu Nov 26 09:09:17 CET 2015 pass
> Thu Nov 26 09:09:29 CET 2015 pass
> Thu Nov 26 09:09:41 CET 2015 FAIL!

so far no luck on my side.. from quick check over the fail log
it seems the patch I sent yesterday could help:

http://lkml.iu.edu/hypermail/linux/kernel/1511.3/00186.html

I'll have more detailed check on your fail log,

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276268

FromJiri Olsa <jolsa@redhat.com>
Date2015-11-24 11:30 +0100
Message-ID<qyj1f-6Rp-7@gated-at.bofh.it>
In reply to#1276143
On Tue, Nov 24, 2015 at 09:10:42AM +0100, Ingo Molnar wrote:

SNIP

> >  tools/perf/util/unwind-libdw.c           |  53 +++++++++++-----
> >  tools/perf/util/unwind-libdw.h           |   2 +
> >  tools/perf/util/unwind-libunwind.c       |  60 +++++++++++-------
> >  11 files changed, 272 insertions(+), 39 deletions(-)
> >  create mode 100644 tools/perf/Documentation/perf-config.txt
> >  create mode 100644 tools/perf/builtin-config.c
> 
> Hm, I noticed something weird - I think it started with this pull request - the 
> feature detection build messages come mixed with the regular build:
> 
> triton:~/tip/tools/perf> make
>   BUILD:   Doing 'make -j12' parallel build
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ on  ]
> ...                      libaudit: [ on  ]
> ...                        libbfd: [ on  ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ on  ]
> ...        numa_num_possible_cpus: [ on  ]
> ...                       libperl: [ on  ]
> ...                     libpython: [ on  ]
> ...                      libslang: [ on  ]
> ...                     libunwind: [ on  ]
> ...            libdw-dwarf-unwind: [ on  ]
> ...                          zlib: [ on  ]
> ...                          lzma: [ on  ]
> ...                     get_cpuid: [ on  ]
> ...                           bpf: [ on  ]
> 
>   GEN      common-cmds.h
>   CC       perf-read-vdso32
>   CC       perf-read-vdsox32
>   CC       ui/gtk/browser.o
>   CC       ui/gtk/hists.o
>   CC       ui/gtk/setup.o
>   CC       ui/gtk/util.o
>   CC       ui/gtk/helpline.o
>   CC       ui/gtk/progress.o
>   CC       ui/gtk/annotate.o
>   CC       util/abspath.o
>   CC       fd/array.o
> 
> Auto-detecting system features:
>   CC       event-parse.o
> ...                        libelf: [ on  ]
>   PERF_VERSION = 4.4.rc2.g9327ca
> ...                           bpf: [ on  ]
> 
>   CC       util/alias.o
>   CC       libbpf.o


so how about we let perf do the overall checking and propagate
that via include file that will setup feature-$(feature) variables

if bpf is built by perf, perf passes this makefile include path
and bpf includes it.. otherwise it runs the standard detection

please test attached patch (bpf guys mainly ;-) )

if that works for you, I'll clean it up a bit and post

thanks,
jirka


---
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 37ff4c9f92f1..a8a65ff010a4 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -131,6 +131,8 @@ ifeq ($(dwarf-post-unwind),1)
   FEATURE_DUMP += dwarf-post-unwind($(dwarf-post-unwind-text))
 endif
 
+FEATURE_INCLUDE_FILENAME = $(OUTPUT)FEATURE-DUMP$(FEATURE_USER).include
+
 # The $(feature_display) controls the default detection message
 # output. It's set if:
 # - detected features differes from stored features from
@@ -140,6 +142,8 @@ endif
 
 ifneq ("$(FEATURE_DUMP)","$(FEATURE_DUMP_FILE)")
   $(shell echo "$(FEATURE_DUMP)" > $(FEATURE_DUMP_FILENAME))
+  $(shell rm -f $(FEATURE_INCLUDE_FILENAME))
+  $(foreach feat,$(FEATURE_TESTS),$(shell echo "feature-$(feat)=$(feature-$(feat))" >> $(FEATURE_INCLUDE_FILENAME)))
   feature_display := 1
 endif
 
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index a3caaf3eafbd..0177bf81f826 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -71,7 +71,11 @@ FEATURE_DISPLAY = libelf bpf
 INCLUDES = -I. -I$(srctree)/tools/include -I$(srctree)/arch/$(ARCH)/include/uapi -I$(srctree)/include/uapi
 FEATURE_CHECK_CFLAGS-bpf = $(INCLUDES)
 
+ifeq ($(FEATURES),)
 include $(srctree)/tools/build/Makefile.feature
+else
+include $(FEATURES)
+endif
 
 export prefix libdir src obj
 
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 929a32ba15f5..4f18c1210509 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -431,7 +431,7 @@ $(LIBAPI)-clean:
 	$(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
 
 $(LIBBPF): fixdep FORCE
-	$(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) $(OUTPUT)libbpf.a
+	$(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) $(OUTPUT)libbpf.a FEATURES=$(realpath $(OUTPUT)FEATURE-DUMP.include)
 
 $(LIBBPF)-clean:
 	$(call QUIET_CLEAN, libbpf)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278061

FromIngo Molnar <mingo@kernel.org>
Date2015-11-26 09:20 +0100
Message-ID<qyZWy-2oi-27@gated-at.bofh.it>
In reply to#1276143
* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > Hi Ingo,
> > 
> > 	Please consider pulling,
> > 
> > - Arnaldo
> > 
> > 
> > The following changes since commit b7883a1c4f75edb62fc49da6000c59fb881e3c7b:
> > 
> >   perf/x86: Handle multiple umask bits for BDW CYCLE_ACTIVITY.* (2015-11-23 09:58:27 +0100)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo
> > 
> > for you to fetch changes up to 646a6e846c4dc3812c614fd061603b6db5b8d380:
> > 
> >   perf callchain: Add missing parent_val initialization (2015-11-23 18:31:25 -0300)
> > 
> > ----------------------------------------------------------------
> > perf/core improvements and fixes:
> > 
> > User visible:
> > 
> > - Allow callchain order (caller, callee) to the libdw and libunwind based DWARF
> >   unwinders (Jiri Olsa)
> > 
> > - Add missing parent_val initialization in the callchain code, fixing a
> >   SEGFAULT when using callchains with 'perf top' (Jiri Olsa)
> > 
> > - Add initial 'perf config' command, for now just with a --list command to
> >   show the contents of the configuration file in use and a basic man page
> >   describing its format, commands for doing edits and detailed documentation
> >   are being reviewed and proof-read. (Taeung Song)
> > 
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > ----------------------------------------------------------------
> > Jiri Olsa (5):
> >       perf callchain: Move initial entry call into get_entries function
> >       perf callchain: Add order support for libunwind DWARF unwinder
> >       perf test: Add callchain order setup for DWARF unwinder test
> >       perf callchain: Add order support for libdw DWARF unwinder
> >       perf callchain: Add missing parent_val initialization
> > 
> > Taeung Song (2):
> >       perf tools: Add 'perf config' command
> >       perf config: Add initial man page
> > 
> >  tools/perf/Build                         |   1 +
> >  tools/perf/Documentation/perf-config.txt | 103 +++++++++++++++++++++++++++++++
> >  tools/perf/builtin-config.c              |  66 ++++++++++++++++++++
> >  tools/perf/builtin.h                     |   1 +
> >  tools/perf/command-list.txt              |   1 +
> >  tools/perf/perf.c                        |   1 +
> >  tools/perf/tests/dwarf-unwind.c          |  22 ++++++-
> >  tools/perf/util/callchain.h              |   1 +
> >  tools/perf/util/unwind-libdw.c           |  53 +++++++++++-----
> >  tools/perf/util/unwind-libdw.h           |   2 +
> >  tools/perf/util/unwind-libunwind.c       |  60 +++++++++++-------
> >  11 files changed, 272 insertions(+), 39 deletions(-)
> >  create mode 100644 tools/perf/Documentation/perf-config.txt
> >  create mode 100644 tools/perf/builtin-config.c
> 
> Hm, I noticed something weird - I think it started with this pull request - the 
> feature detection build messages come mixed with the regular build:

As per the discussion that followed, this seems to be an old and unrelated bug, so 
I pulled your tree, thanks a lot Arnaldo!

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web