Message-ID: <20150923134456.GD5041@redhat.com>
Date:	Wed, 23 Sep 2015 10:44:56 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Vinson Lee <vlee@...pensource.com>, rostedt@...dmis.org,
	Jiri Olsa <jolsa@...nel.org>, raphael.beamonte@...il.com,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Namhyung Kim <namhyung@...nel.org>,
	linux-tip-commits@...r.kernel.org,
	Michael Petlan <mpetlan@...hat.com>
Subject: Re: [tip:perf/core] tools lib api fs: Remove debugfs, tracefs and
 findfs objects

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists