[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131001120455.GA8001@gmail.com>
Date: Tue, 1 Oct 2013 14:04:55 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
David Ahern <dsahern@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Jiri Olsa <jolsa@...hat.com>, Namhyung Kim <namhyung@...il.com>
Subject: Re: [PATCH] perf autodep: Remove strlcpy feature check, add __weak
strlcpy implementation
* Ingo Molnar <mingo@...nel.org> wrote:
> Overhead is down from 0.600 secs to 0.540 secs. The only remaining thing
> is the libperl bug, I'll have a look at that next.
So, libperl detection works fine here, once I've installed the prereq
package on Fedora, "perl-ExtUtils-Embed":
comet:~/tip/tools/perf> make Makefile
Auto-detecting system features:
... stackprotector-all: [ on ]
... volatile-register-var: [ on ]
... fortify-source: [ on ]
... libelf: [ on ]
... libelf-mmap: [ on ]
... glibc: [ on ]
... dwarf: [ on ]
... libelf-getphdrnum: [ on ]
... libunwind: [ on ]
... libaudit: [ on ]
... libslang: [ on ]
... gtk2: [ on ]
... gtk2-infobar: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libpython-version: [ on ]
... libbfd: [ on ]
... on-exit: [ on ]
... backtrace: [ on ]
... libnuma: [ on ]
Time is down to 0.480 sec because there are no build failures now, only
Make re-checking the dependencies of already built binaries.
And the actual feature check is roughly 0.330 msecs of that:
comet:~/tip/tools/perf/config/feature-checks> time ( make -j >/dev/null; \
for N in stackprotector-all volatile-register-var fortify-source libelf \
libelf-mmap glibc dwarf libelf-getphdrnum libunwind libaudit libslang gtk2 \
gtk2-infobar libperl libpython libpython-version libbfd on-exit backtrace \
libnuma; do make test-$N >/dev/null; done )
real 0m0.330s
user 0m0.290s
sys 0m0.031s
With 0.150 msecs spent elsewhere.
So there's more speedups possible I think, for example we could construct
an 'optimistic' testcase that is generated live and includes a
concatenation of all the testcases.
If the build of that file succeeds then we have a really efficient
fast-path both in the first-build and in the repeat-build case.
If that build fails then we do the more finegrained feature check.
Thoughts?
Thanks,
Ingo
--
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