Em Wed, Sep 23, 2015 at 10:39:06AM +0200, Jiri Olsa escreveu:
> On Wed, Sep 23, 2015 at 09:23:02AM +0100, Matt Fleming wrote:
> > On Mon, 21 Sep, at 05:20:03PM, Vinson Lee wrote:
> > > This commit seems to have introduced a build failure with tools/vm.
> > >
> > > $ make -C tools vm
> > > [...]
> > > gcc -Wall -Wextra -I../lib/ -o page-types page-types.c ../lib/api/libapi.a
> > > page-types.c:45:28: fatal error: api/fs/debugfs.h: No such file or directory
> > > #include <api/fs/debugfs.h>
> >
> > Given the ferocious pace of development of tools/perf, is there not
> > some kind of automated build that happens when new patches are picked
> > up, before they're pushed out?
> > Things are refactored and changed so fast in this area (I dare say
> > faster than almost any other part of the kernel source tree) that not
> > having the safety net of automated builds just seems suicidal.
Well, I don't want to die, and I work with people that would kill me if
I behaved that way, so I think its not _that_ bad, there are safeguards,
and we're always thinking about adding some more. 8-)
> > And that doesn't even begin to cover runtime testing, since I've
> > noticed things breaking in tools/perf and people not catching it
> > immediately.
> >
> > Does automated testing exist for perf tools development?
> heh, we've been playing game "who first mention it in public will
> implement it" ... you won! ;-)
Nah, you did lotsa already with tools/perf/tests/make
[acme@zoo linux]$ grep ^make tools/perf/tests/make
make_clean_all := clean all
make_python_perf_so := python/perf.so
make_debug := DEBUG=1
make_no_libperl := NO_LIBPERL=1
make_no_libpython := NO_LIBPYTHON=1
make_no_scripts := NO_LIBPYTHON=1 NO_LIBPERL=1
make_no_newt := NO_NEWT=1
make_no_slang := NO_SLANG=1
make_no_gtk2 := NO_GTK2=1
make_no_ui := NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_no_demangle := NO_DEMANGLE=1
make_no_libelf := NO_LIBELF=1
make_no_libunwind := NO_LIBUNWIND=1
make_no_libdw_dwarf_unwind := NO_LIBDW_DWARF_UNWIND=1
make_no_backtrace := NO_BACKTRACE=1
make_no_libnuma := NO_LIBNUMA=1
make_no_libaudit := NO_LIBAUDIT=1
make_no_libbionic := NO_LIBBIONIC=1
make_no_auxtrace := NO_AUXTRACE=1
make_tags := tags
make_cscope := cscope
make_help := help
make_doc := doc
make_perf_o := perf.o
make_util_map_o := util/map.o
make_util_pmu_bison_o := util/pmu-bison.o
make_install := install
make_install_bin := install-bin
make_install_doc := install-doc
make_install_man := install-man
make_install_html := install-html
make_install_info := install-info
make_install_pdf := install-pdf
make_install_prefix := install prefix=/tmp/krava
make_install_prefix_slash := install prefix=/tmp/krava/
make_static := LDFLAGS=-static
make_minimal := NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1
make_minimal += NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1
NO_BACKTRACE=1
make_minimal += NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1
make_minimal += NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1
make_kernelsrc:
make_kernelsrc_tools:
[acme@zoo linux]$
This takes a lot of testing, I plan on using TypeChef to speed that up
and increase the number of tests:
https://github.com/ckaestne/TypeChef-LinuxAnalysis/blob/master/README.md
And 'perf test' has 40 tests, with some being really a multiplexor, like
the perf_event_attr ones, that will run the tools and look at how they
set up perf_event_attr for multiple command line options:
[root@zoo ~]# perf test | tail -10
31: Test output sorting of hist entries : Ok
32: Test cumulation of child hist entries : Ok
33: Test tracking with sched_switch : Ok
34: Filter fds with revents mask in a fdarray : Ok
35: Add fd to a fdarray, making it autogrow : Ok
36: Test kmod_path__parse function : Ok
37: Test thread map : Ok
38: Test LLVM searching and compiling : (skip bpf parsing) Ok
39: Test x86 instruction decoder - new instructions : Ok
40: Test topology in session : Ok
[root@zoo ~]#
New stuff normally comes with new 'perf test' entries, Intel PT borrowed
the kernel x86 instruction decoder: added a 'perf test' entry, AFAIK
there was no similar test for it in the kernel proper, IIRC Masami plans
to do it.
The attr one you can look at:
[acme@zoo linux]$ ls -la tools/perf/tests/attr/test-* | wc -l
33
> AFAIK we have:
> - 'perf test' for perf specific functionality
> - 'make -f tests/make' for building
> - build framework tests
>
> I 'try' to run those before sending anything out, but we dont have
> automated thing that would run it any time Arnaldo push new perf/core.
Well, I do run it in multiple distros, like RHEL5, RHEL6 and RHEL7
besides Fedora 21.
We're getting used to tools/{lib,include}/ so this happened, but
otherwise I don't feel like there are that many problems cropping up as
you seem to think :-\
Of course, in these days of CI, I'd love if someone would hook 'make -C
tools/perf build-test' and 'perf test' somewhere to be run for every
changeset.
> The RedHat QE has some more perf tool tests. There was some movement
> to make those public, but not sure how it ended up.. ccing Michael Petlan
> for news on this ;-)
Yeah, this too has helped catch and fix problems.
BTW, tools/vm/ was reported yesterday and a fix is already in
tip/perf/core/:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/tools/vm?id=f6489bc2d402c0db84aa64f13b864d17f7eecb07
Age Commit message (Expand) Author Files Lines
12 hours tools vm: Fix build due to removal of tools/lib/api/fs/debugfs.h Arnaldo Carvalho de Melo 1 -3/+3
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|