kernel/linux.git/tools/perf/bench, branch v3.6.6

perf bench: Fix confused variable namings and descriptions in mem subsystem

2012-07-02T17:35:45+00:00

As Namhyung Kim pointed, there are confused namings and descriptions of words "cycle" and "clock" in mem-memset.c and mem-memcpy.c. With the option "-c" (or "--clock", now renamed as "--cycle"), mem subsystem measures cost of memset() and memcpy() with cpu-cycles event. But current mem subsystem source code contains lots of confused variable namings and descriptions with "clock" (e.g. the variable use_clock). This is a very bad style because there is another software event named "cpu-clock". This patch replaces wrong usage of "clock" to "cycle". v2: modified Documentation/perf-bench.txt for the descriptions of --cycle option Signed-off-by: Hitoshi Mitake Cc: Ingo Molnar Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1341236777-18457-1-git-send-email-h.mitake@gmail.com Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Documentation update

2012-06-27T16:17:48+00:00

The current perf-bench documentation has a couple of typos and even lacks entire description of mem subsystem. Fix it. Reported-by: Ingo Molnar Signed-off-by: Namhyung Kim Acked-by: Hitoshi Mitake Cc: Hitoshi Mitake Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1340172486-17805-1-git-send-email-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf tool: Fix perf stack to non executable on x86_64

2012-02-06T21:14:17+00:00

By adding following objects: bench/mem-memset-x86-64-asm.o bench/mem-memcpy-x86-64-asm.o the x86_64 perf binary ended up with executable stack. The reason was that above objects are assembler sourced and are missing the GNU-stack note section. In such case the linker assumes that the final binary should not be restricted at all and mark the stack as RWX. Adding section ".note.GNU-stack" definition to mentioned objects, with all flags disabled, thus omiting those objects from linker stack flags decision. Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570 Reported-by: Clark Williams Acked-by: Eric Dumazet Cc: Corey Ashford Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com Signed-off-by: Jiri Olsa [ committer note: Remaining bits after what was already added to perf/urgent ] Signed-off-by: Arnaldo Carvalho de Melo

Merge branch 'perf/urgent' into perf/core

2012-02-06T21:11:02+00:00

So that we can get the perf bench exec stack fixes and then apply the remaining fix for the files added after what is in perf/urgent. Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Fix perf stack to non executable on x86_64

2012-02-06T20:54:06+00:00

By adding following objects: bench/mem-memcpy-x86-64-asm.o the x86_64 perf binary ended up with executable stack. The reason was that above object are assembler sourced and is missing the GNU-stack note section. In such case the linker assumes that the final binary should not be restricted at all and mark the stack as RWX. Adding section ".note.GNU-stack" definition to mentioned object, with all flags disabled, thus omiting this object from linker stack flags decision. Problem introduced in: $ git describe ea7872b v2.6.37-rc2-19-gea7872b Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570 Reported-by: Clark Williams Acked-by: Eric Dumazet Cc: Corey Ashford Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: stable@kernel.org Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com Signed-off-by: Jiri Olsa [ committer note: Backported fix to perf/urgent (3.3-rc2+) ] Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Remove unnecessary ctype.h inclusion

2012-01-30T20:37:35+00:00

There are unnecessary #include out there, and they might cause a nasty build failure in some environment. As we already have most of ctype macros in util.h, just get rid of them. A few of exceptions are util/symbol.c which needs isupper() macro util.h doesn't provide and perl scripting support code which includes ctype.h internally. Suggested-by: Ingo Molnar Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1327827356-8786-4-git-send-email-namhyung@gmail.com Signed-off-by: Namhyung Kim Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Allow passing an iteration count to "bench mem mem{cpy,set}"

2012-01-24T22:26:10+00:00

"perf stat ... perf bench mem mem..." is pretty meaningless when using small block sizes (as the overhead of the invocation of each test run basically hides the actual test result in the noise). Repeating the actually interesting function's invocation a number of times allows the results to become meaningful. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/4F16D767020000780006D738@nat28.tlf.novell.com Signed-off-by: Jan Beulich Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Also allow measuring memset()

2012-01-24T22:25:32+00:00

This simply clones the respective memcpy() implementation. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/4F16D743020000780006D735@nat28.tlf.novell.com Signed-off-by: Jan Beulich Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Also allow measuring alternative memcpy implementations

2012-01-24T21:51:01+00:00

Intended to be able to support the current selection of the preferred memcpy() implementation, this patch adds the ability to also measure the two alternative implementations, again by way of using some pre-processsor replacement. While on my Westmere system this proves that the movsb based variant is worse than the movsq based one (since the ERMS feature isn't there), it also shows that here for the default as well as small sizes the unrolled variant outperforms the movsq one. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/4F16D728020000780006D732@nat28.tlf.novell.com Signed-off-by: Jan Beulich Signed-off-by: Arnaldo Carvalho de Melo

perf bench: Make "default" memcpy() selection actually use glibc's implementation

2012-01-24T21:50:19+00:00

Since arch/x86/lib/memcpy_64.S implements not only __memcpy, but also memcpy, without further precautions this function will get chose by the static linker for resolving all references, and hence the "default" measurement didn't really measure anything else than the "x86-64-unrolled" one. Fix this by renaming (through the pre-processor) the conflicting symbol. On my Westmere system, the glibc variant turns out to require about 4% less instructions, but 15% more cycles for the default 1Mb block size measured. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/4F16D6FD020000780006D72F@nat28.tlf.novell.com Signed-off-by: Jan Beulich Signed-off-by: Arnaldo Carvalho de Melo