Em Fri, Oct 26, 2012 at 05:34:32PM +0200, Borislav Petkov escreveu:
> On Sat, Oct 27, 2012 at 12:31:42AM +0900, Namhyung Kim wrote:
> > You can see it easily when building perf without -j option. But I have
> > no idea why it takes so long..
> Well, you can trace that workload with perf itself, no, and see the
> hotspots.
Right, perf'ing perf is a favourite pastime, right?
Em Fri, Oct 26, 2012 at 04:54:51PM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <a...@infradead.org> wrote:
> > . Makefile improvements from Namhyung Kim.
> These are really useful: there used to be a couple of seconds of > wait time at the beginning of every perf build - these are now > nicely explained with the various CHK entries.
The optimal way, I guess, would be to have some cache file with the
results of such feature tests, that would be created and then used till
the build fails using its findings, which would trigger a new feature
check round, followed by an automatic rebuild.
That would be tricky because we would have to have an automated way of
discovering if the build failed due to missing packages or if it failed
due to some ordinary coding mistake.
> Em Fri, Oct 26, 2012 at 04:54:51PM +0200, Ingo Molnar escreveu:
> > * Arnaldo Carvalho de Melo <a...@infradead.org> wrote:
> > > . Makefile improvements from Namhyung Kim.
> > These are really useful: there used to be a couple of > > seconds of wait time at the beginning of every perf build - > > these are now nicely explained with the various CHK entries.
> The optimal way, I guess, would be to have some cache file > with the results of such feature tests, that would be created > and then used till the build fails using its findings, which > would trigger a new feature check round, followed by an > automatic rebuild.
> That would be tricky because we would have to have an > automated way of discovering if the build failed due to > missing packages or if it failed due to some ordinary coding > mistake.
The feature tests aren't a big problem right now - but making it *visible* is really useful. It also tells us which feature test fails, etc.
> PERF-VERSION-GEN and specifically the git commands are the > cause of more delay than the config checks, especially when > doing the build in a VM with the kernel source on an NFS > mount.
Yes, I have noticed that too.
So, the problem is that we use 'git describe' on the kernel tree to generate the version string, which is very, very slow if we are far away from any tagged release - which is the case for the -tip tree:
On Fri, Oct 26, 2012 at 5:31 PM, Namhyung Kim <namhy...@kernel.org> wrote:
> 2012-10-26 (금), 09:06 -0600, David Ahern:
>> On 10/26/12 8:54 AM, Ingo Molnar wrote:
>> >> perf/core improvements:
>> >> . perf inject changes to allow showing where a task sleeps, from Andrew Vagin.
>> >> . Makefile improvements from Namhyung Kim.
>> > These are really useful: there used to be a couple of seconds of
>> > wait time at the beginning of every perf build - these are now
>> > nicely explained with the various CHK entries.
> Kudos to Jiri who did the real work!
>> PERF-VERSION-GEN and specifically the git commands are the cause of more
>> delay than the config checks, especially when doing the build in a VM
>> with the kernel source on an NFS mount.
> And I see a strange delay when compiling builtin-sched.o. After
> building perf tools, I deleted builtin-{sched,test,script}.o to rebuild
> the only since they are largest ones.
Yes, I see that delay on copiling builtin-sched.c on my IVB system.
Don't know why it takes a significant number of seconds to compile
this file. It did not use to be like that a few revisions back. It takes
about 8 seconds on my OC'd IVB (> 4GHz). I don't see much code
in that file.
> * Arnaldo Carvalho de Melo <a...@infradead.org> wrote:
> > Em Fri, Oct 26, 2012 at 04:54:51PM +0200, Ingo Molnar escreveu:
> > > * Arnaldo Carvalho de Melo <a...@infradead.org> wrote:
> > > > . Makefile improvements from Namhyung Kim.
> > > These are really useful: there used to be a couple of > > > seconds of wait time at the beginning of every perf build - > > > these are now nicely explained with the various CHK entries.
> > The optimal way, I guess, would be to have some cache file > > with the results of such feature tests, that would be created > > and then used till the build fails using its findings, which > > would trigger a new feature check round, followed by an > > automatic rebuild.
> > That would be tricky because we would have to have an > > automated way of discovering if the build failed due to > > missing packages or if it failed due to some ordinary coding > > mistake.
> The feature tests aren't a big problem right now - but making > it *visible* is really useful. It also tells us which feature > test fails, etc.
Btw., there's another thing that would be nice in addition to simplifying the PERF-VERSION-GEN script: to be able to run the CHK tests in parallel, like the object file runes.
Right now the CHK tests are serialized and they take several seconds to build and run. A parallel make rule would reduce
that to about a second I think.
On Tue, 2012-10-30 at 09:18 +0100, Ingo Molnar wrote:
> > > The optimal way, I guess, would be to have some cache file > > > with the results of such feature tests, that would be created > > > and then used till the build fails using its findings, which > > > would trigger a new feature check round, followed by an > > > automatic rebuild.
> Btw., there's another thing that would be nice in addition to > simplifying the PERF-VERSION-GEN script: [...]
Here's a stab at that.
----------------->
Building perf is pretty slow on trees that have a lot of commits relative to the nearest Git tag. This slowness manifests itself during version string generation:
Performance counter stats for 'util/PERF-VERSION-GEN' (3 runs):
2.857503976 seconds time elapsed ( +- 0.22% )
The build can be even slower than that, when one over NFS volumes.
The reason for the slowness is that util/PERF-VERSION-GEN uses "git describe" to generate the string, which has to count the "number of commits distance" from the nearest tag - the ".1458." count in the output above. For that Git had to extract and decompress 1458 Git objects, which takes time and bandwidth.
But this "number of commits" value is mostly irrelevant in practice. We either want to know an approximate tag name, or we want to know the precise sha1.
So this patch simplifies the version string to:
PERF_VERSION = 3.7.rc3.g5399b3b.dirty
which speeds up the version string generation script by an order of magnitude:
diff --git a/tools/perf/util/PERF-VERSION-GEN b/tools/perf/util/PERF-VERSION-GEN
index 95264f3..c774b89 100755
--- a/tools/perf/util/PERF-VERSION-GEN
+++ b/tools/perf/util/PERF-VERSION-GEN
@@ -12,7 +12,7 @@ LF='
# First check if there is a .git to get the version from git describe
# otherwise try to get the version from the kernel makefile
if test -d ../../.git -o -f ../../.git &&
- VN=$(git describe --match 'v[0-9].[0-9]*' --abbrev=4 HEAD 2>/dev/null) &&
+ VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
There's another source of overhead in the perf version string generator:
git update-index -q --refresh
.. which will iterate the whole checked out tree. This can be pretty slow on NFS volumes, but takes some time even with local SSD disks and a fully cached kernel tree:
Performance counter stats for 'util/PERF-VERSION-GEN' (3 runs):
0.306999221 seconds time elapsed ( +- 0.56% )
So remove the .dirty differentiator as well - it adds little information because locally patched git trees are common, but seldom are the perf tools modified.
So a lot of version strings are reported as 'dirty' while in fact they are pristine perf builds. For example 99% of my perf builds are not patched but the kernel tree is slightly patched, which adds the .dirty tag.
Eliminating that tag speeds up version generation by another order of magnitude:
+#
# First check if there is a .git to get the version from git describe
-# otherwise try to get the version from the kernel makefile
+# otherwise try to get the version from the kernel Makefile
+#
if test -d ../../.git -o -f ../../.git &&
- VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
- case "$VN" in
- *$LF*) (exit 1) ;;
- v[0-9]*)
- git update-index -q --refresh
- test -z "$(git diff-index --name-only HEAD --)" ||
- VN="$VN-dirty" ;;
- esac
+ VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null)
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> On Tue, 2012-10-30 at 09:18 +0100, Ingo Molnar wrote:
> > > > The optimal way, I guess, would be to have some cache file > > > > with the results of such feature tests, that would be created > > > > and then used till the build fails using its findings, which > > > > would trigger a new feature check round, followed by an > > > > automatic rebuild.
I did not write that.
I think making the feature tests parallel would be enough to speed it all up - caching brings in a new set of problems. The tests are mostly independent and the feature test makefile rules could be parallelized like the object file rules.
> autoconf!! ;-)
> /me runs
hey, we build perf much faster than autoconf's 'configure' script finishes running ;-)
Discussion subject changed to "perf tools: Speed up the perf build time by simplifying the perf --version string generation" by Arnaldo Carvalho de Melo
Em Tue, Oct 30, 2012 at 09:46:00AM +0100, Ingo Molnar escreveu:
> +++ b/tools/perf/util/PERF-VERSION-GEN
> @@ -12,7 +12,7 @@ LF='
> # First check if there is a .git to get the version from git describe
> # otherwise try to get the version from the kernel makefile
> if test -d ../../.git -o -f ../../.git &&
> - VN=$(git describe --match 'v[0-9].[0-9]*' --abbrev=4 HEAD 2>/dev/null) &&
> + VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
> Em Tue, Oct 30, 2012 at 09:46:00AM +0100, Ingo Molnar escreveu:
> > +++ b/tools/perf/util/PERF-VERSION-GEN
> > @@ -12,7 +12,7 @@ LF='
> > # First check if there is a .git to get the version from git describe
> > # otherwise try to get the version from the kernel makefile
> > if test -d ../../.git -o -f ../../.git &&
> > - VN=$(git describe --match 'v[0-9].[0-9]*' --abbrev=4 HEAD 2>/dev/null) &&
> > + VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
> * Arnaldo Carvalho de Melo <a...@infradead.org> wrote:
> > Em Tue, Oct 30, 2012 at 09:46:00AM +0100, Ingo Molnar escreveu:
> > > +++ b/tools/perf/util/PERF-VERSION-GEN
> > > @@ -12,7 +12,7 @@ LF='
> > > # First check if there is a .git to get the version from git describe
> > > # otherwise try to get the version from the kernel makefile
> > > if test -d ../../.git -o -f ../../.git &&
> > > - VN=$(git describe --match 'v[0-9].[0-9]*' --abbrev=4 HEAD 2>/dev/null) &&
> > > + VN=$(echo $(git tag --list "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
> this will work silently even if Git is not installed.
But we first check if we have a .git, that doesn't guarantees that git
is installed, but makes it a lot likely, no? Redirecting stderr to null
would need to be done in more places, so we would need to use something
like what we do for xmlto/asciidoc, $(call get-executable,$(GIT))
#
# First check if there is a .git to get the version from git describe
# otherwise try to get the version from the kernel Makefile
#
if test -d ../../.git -o -f ../../.git &&
VN=$(echo $(git tag -l "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null)
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
VN=$(MAKEFLAGS= make -sC ../.. kernelversion)
fi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> > this will work silently even if Git is not installed.
> But we first check if we have a .git, that doesn't guarantees > that git is installed, but makes it a lot likely, no? > [...]
Not necessarily - say a home directory is NFS shared to multiple test boxes, one does not have Git installed.
> Redirecting stderr to null would need to be done in more > places, so we would need to use something like what we do for > xmlto/asciidoc, $(call get-executable,$(GIT))
It at least solves it in this particular case, and I tested it with Git uninstalled, there's no extra message just a proper error code the script can use to fall back to the toplevel Makefile for version info.
for you to fetch changes up to ffadcf090d468e9c4938b718649f38dd10cfdb02:
perf annotate: Handle XBEGIN like a jump (2012-10-31 12:18:26 -0200)
----------------------------------------------------------------
perf/core improvements and fixes
Handle XBEGIN like a jump in the annotate browser, from Andi Kleen
Build speedups for --version, from Ingo Molnar.
Add info about cross compiling for Android ARM, from Joonsoo Kim.
Warn about missing libelf, from Namhyung Kim.
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
----------------------------------------------------------------
Andi Kleen (1):
perf annotate: Handle XBEGIN like a jump
Arnaldo Carvalho de Melo (1):
perf tools: Handle --version string generation on machines without git
Ingo Molnar (2):
perf tools: Speed up the perf build time by simplifying the perf --version string generation
perf tools: Further speed up the perf build
Joonsoo Kim (1):
perf tools: Add info about cross compiling for Android ARM
Namhyung Kim (1):
perf tools: Warn about missing libelf
tools/perf/Documentation/android.txt | 5 ++++-
tools/perf/Makefile | 2 ++
tools/perf/util/PERF-VERSION-GEN | 14 +++++---------
tools/perf/util/annotate.c | 2 ++
4 files changed, 13 insertions(+), 10 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> > PERF-VERSION-GEN and specifically the git commands are the > > cause of more delay than the config checks, especially when > > doing the build in a VM with the kernel source on an NFS > > mount.
> Yes, I have noticed that too.
...
> The cost on this pretty fast machine is about 1 msecs per commit > - which adds up to about 2.5 seconds during much of the > development cycle.
Well... I noticed my builds when little changed are very slow... and
it was due to the computation of version string. Ouch.
(Cached it is more reasonable 3 seconds, but it keeps going out of
cache all the time. Uncached clean build is 3 minutes, cached is 9
seconds + time to do git describe).
for you to fetch changes up to 8dfec403e39b7c37fd6e8813bacc01da1e1210ab:
perf tests: Removing 'optional' field (2012-11-05 14:03:59 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
Don't show scripts menu for 'perf top', fix from Feng Tang
Add framework for automated perf_event_attr tests, where tools with different
command line options will be run from a 'perf test', via python glue, and the
perf syscall will be intercepted to verify that the perf_event_attr fields
set by the tool are those expected, from Jiri Olsa
Use normalized arch name for searching objdump path. This fixes cases
where the system's objdump (e.g. x86_64) supports the architecture in
the perf.data file (e.g. i686), but is not the same, fix from Namhyung Kim.
Postpone objdump check until annotation requested, from Namhyung Kim.
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
----------------------------------------------------------------
Feng Tang (1):
perf browser: Don't show scripts menu for 'perf top'
Jiri Olsa (28):
perf tools: Remove BINDIR define from exec_cmd.o compilation
perf tests: Move test objects into 'tests' directory
perf tests: Add framework for automated perf_event_attr tests
perf tests: Add attr record basic test
perf tests: Add attr tests under builtin test command
perf tests: Add attr record group test
perf tests: Add attr record event syntax group test
perf tests: Add attr record freq test
perf tests: Add attr record count test
perf tests: Add attr record graph test
perf tests: Add attr record period test
perf tests: Add attr record no samples test
perf tests: Add attr record no-inherit test
perf tests: Add attr record data test
perf tests: Add attr record raw test
perf tests: Add attr record no delay test
perf tests: Add attr record branch any test
perf tests: Add attr record branch filter tests
perf tests: Add attr stat no-inherit test
perf tests: Add attr stat group test
perf tests: Add attr stat event syntax group test
perf tests: Add attr stat default test
perf tests: Add attr stat default test
perf tests: Add documentation for attr tests
perf tests: Add missing attr stat basic test
perf tests: Factor attr tests WRITE_ASS macro
perf tests: Fix attr watermark field name typo
perf tests: Removing 'optional' field
Namhyung Kim (3):
perf tools: Use normalized arch name for searching objdump path
perf tools: Introduce struct hist_browser_timer
perf report: Postpone objdump check until annotation requested
Discussion subject changed to "perf tools: Speed up the perf build time by simplifying the perf --version string generation" by tip-bot for Ingo Molnar
Commit-ID: acddedfba0df1e47fa99035a04661082b679ee9c
Gitweb: http://git.kernel.org/tip/acddedfba0df1e47fa99035a04661082b679ee9c Author: Ingo Molnar <mi...@kernel.org>
AuthorDate: Tue, 30 Oct 2012 09:46:00 +0100
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Wed, 31 Oct 2012 12:17:49 -0200
perf tools: Speed up the perf build time by simplifying the perf --version string generation
Building perf is pretty slow on trees that have a lot of commits
relative to the nearest Git tag. This slowness manifests itself during
version string generation:
Performance counter stats for 'util/PERF-VERSION-GEN' (3 runs):
2.857503976 seconds time elapsed ( +- 0.22% )
The build can be even slower than that, when one over NFS volumes.
The reason for the slowness is that util/PERF-VERSION-GEN uses "git
describe" to generate the string, which has to count the "number of
commits distance" from the nearest tag - the ".1458." count in the
output above. For that Git had to extract and decompress 1458 Git
objects, which takes time and bandwidth.
But this "number of commits" value is mostly irrelevant in practice. We
either want to know an approximate tag name, or we want to know the
precise sha1.
So this patch simplifies the version string to:
PERF_VERSION = 3.7.rc3.g5399b3b.dirty
which speeds up the version string generation script by an order of
magnitude:
Performance counter stats for 'util/PERF-VERSION-GEN' (3 runs):
0.307633559 seconds time elapsed ( +- 0.84% )
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Cc: Andrew Vagin <ava...@openvz.org>
Cc: Borislav Petkov <b...@amd64.org>
Cc: David Howells <dhowe...@redhat.com>
Cc: Frederic Weisbecker <fweis...@gmail.com>
Cc: Jiri Olsa <jo...@redhat.com>
Cc: Namhyung Kim <namhy...@kernel.org>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Peter Zijlstra <a.p.zijls...@chello.nl>
Cc: Stephane Eranian <eran...@gmail.com>
Cc: Steven Rostedt <rost...@goodmis.org>
Link: http://lkml.kernel.org/r/20121030084600.GB8...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
tools/perf/util/PERF-VERSION-GEN | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/PERF-VERSION-GEN b/tools/perf/util/PERF-VERSION-GEN
index 95264f3..f6e8ee2 100755
--- a/tools/perf/util/PERF-VERSION-GEN
+++ b/tools/perf/util/PERF-VERSION-GEN
@@ -12,7 +12,7 @@ LF='
# First check if there is a .git to get the version from git describe
# otherwise try to get the version from the kernel makefile
if test -d ../../.git -o -f ../../.git &&
- VN=$(git describe --match 'v[0-9].[0-9]*' --abbrev=4 HEAD 2>/dev/null) &&
+ VN=$(echo $(git tag -l "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Commit-ID: 0e2af956693a8797d658d076ff4c0da4147f0131
Gitweb: http://git.kernel.org/tip/0e2af956693a8797d658d076ff4c0da4147f0131 Author: Ingo Molnar <mi...@kernel.org>
AuthorDate: Tue, 30 Oct 2012 09:54:41 +0100
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Wed, 31 Oct 2012 12:17:49 -0200
perf tools: Further speed up the perf build
There's another source of overhead in the perf version string generator:
git update-index -q --refresh
.. which will iterate the whole checked out tree. This can be pretty
slow on NFS volumes, but takes some time even with local SSD disks and a
fully cached kernel tree:
Performance counter stats for 'util/PERF-VERSION-GEN' (3 runs):
0.306999221 seconds time elapsed ( +- 0.56% )
So remove the .dirty differentiator as well - it adds little information
because locally patched git trees are common, but seldom are the perf
tools modified.
So a lot of version strings are reported as 'dirty' while in fact they
are pristine perf builds. For example 99% of my perf builds are not
patched but the kernel tree is slightly patched, which adds the .dirty
tag.
Eliminating that tag speeds up version generation by another order of
magnitude:
+#
# First check if there is a .git to get the version from git describe
-# otherwise try to get the version from the kernel makefile
+# otherwise try to get the version from the kernel Makefile
+#
if test -d ../../.git -o -f ../../.git &&
- VN=$(echo $(git tag -l "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null) &&
- case "$VN" in
- *$LF*) (exit 1) ;;
- v[0-9]*)
- git update-index -q --refresh
- test -z "$(git diff-index --name-only HEAD --)" ||
- VN="$VN-dirty" ;;
- esac
+ VN=$(echo $(git tag -l "v[0-9].[0-9]*" | tail -1)"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD) 2>/dev/null)
then
VN=$(echo "$VN" | sed -e 's/-/./g');
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
