lkml.org 
[lkml]   [2015]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [GIT PULL 0/7] perf/core improvements and fixes
    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

    \
     
     \ /
      Last update: 2015-11-24 11:01    [W:2.442 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site