The behavior of this benchmark includes three steps:
1. Use up to 16 MB by allocating blocks with given size in each thread.
2. Release the all blocks in random order.
3. Use up to 1.6 MB by allocating blocks with given size in each thread.
This is used to see how the allocator manages the free blocks and we can
measure the impact of randomization property used by the allocator.
Test: Run malloc-rss-benchmark $NUM_THREADS $ALLOC_SIZE
Change-Id: Ib68562996905839ee4367b1b059714e2325ca03e
Use /data/local/tests/unrestricted as on-device test path so that
debuggerd can generate proper back traces.
Bug: 199904562
Bug: 184739644
Test: treehugger
Change-Id: I4ae1fb3182dde081121179f1b099374119205dd3
For convenience, builds against musl libc currently use the
linux_glibc properties because they are almost always linux-specific
and not glibc-specific. In preparation for removing this hack,
tweak the linux_glibc properties by either moving them to host_linux,
which will apply to linux_glibc, linux_musl and linux_bionic, or
by setting appropriate musl or linux_musl properties. Properties
that must not be repeated while musl uses linux_musl and also still
uses the linux_glibc properties are moved to glibc properties, which
don't apply to musl. Whether these stay as glibc properties or get
moved back to linux_glibc later once the musl hack is removed is TBD.
Bug: 223257095
Test: m checkbuild
Test: m USE_HOST_MUSL=true host-native
Change-Id: I809bf1ba783dff02f6491d87fbdc9fa7fc0975b0
Fix references to symbols that don't exist in musl in the bionic
benchmarks, and disable the header tests for musl.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: I6b1964afa4a7b6e6a4812e9f2605fcfc2fae9691
A decent chunk of the logcat profile is spent formatting the timestamps
for each line, and most of that time was going to snprintf(3). We should
find all the places that could benefit from a lighter-weight "format an
integer" and share something between them, but this is easy for now.
Before:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 781 ns 775 ns 893102
After:
-----------------------------------------------------------
Benchmark Time CPU Iterations
-----------------------------------------------------------
BM_time_strftime 149 ns 147 ns 4750782
Much of the remaining time is in tzset() which seems unfortunate.
Test: treehugger
Change-Id: Ie0f7ee462ff1b1abea6f87d4a9a996d768e51056
I don't think the old benchmarks made any sense; going through all the
characters might have made sense as a unit test, but I'm not sure how
actionable they were for realistic cases. In particular, "all ASCII" is
a common special case that's worth measuring separately. I'm still not
hugely convinced, but at least separating the "ASCII" and "wide" paths
is an improvement. I can't think of a case where we did optimization
work on this kind of code without considering those two paths
separately.
I've added to the single-character benchmarks by splitting out the
separate cases instead --- one benchmark each for single-byte up to
4-byte characters.
Bug: http://b/206523398
Test: treehugger
Change-Id: I58cbfedb4b497a55580857eff307a024938cf006
Auto-generate NOTICE files for all the directories, and for each one
individually rather than mixing libc and libm together.
Test: N/A
Change-Id: I7e251194a8805c4ca78fcc5675c3321bcd5abf0a
This makes it easy to benchmark changes to bionic without needing
to reflash the device or mess with LD_LIBRARY_PATH.
Change-Id: Ic7ea0f075751f8f077612617802775d2d0a799dc
A lot of these benchmarks predate DoNotOptimize and rolled their own
hacks.
Bug: http://b/148307629
Test: ran benchmarks before & after and got similar results
Change-Id: If44699d261b687f6253af709edda58f4c90fb285
The benchmark calls __cxa_atexit 100000 times, then either exits early
without calling the destructors (_Exit) or exits normally, calling them
(exit).
Test: mmma bionic/benchmarks/spawn
Change-Id: I41fe702d6ef11acb7a1dec95bf546b5dc693bd4a
One turns out not to be used at all, and the pylintrc even uses the more
intention-revealing term in the machine readable part, just not the
comment!
Test: treehugger
Change-Id: I4db7f1cf4fa1aa8ee601857e4e4c400e2119887c
This benchmark also includes the measuring of RSS.
Bug: 137795072
Test: Ran different iterations and verified the RSS_MB value is nearly
Test: identical no matter the number of iterations.
Change-Id: I465a0eae9dcff2e1fb739c35623a26291680951f
Per Wilco Dijkstra at ARM, 16 and 32 byte copies are much more common
than 8 or 64.
Change-Id: I3699d8bcd5f9dd8a8ccd8564a6cf58d2bd7089f5
Suggested-By: Wilco Dijkstra <wilco.dijkstra@arm.com>
Add a calloc benchmark to make sure that a native allocator isn't
doing anything incorrectly when zero'ing memory.
Also add a fork call benchmark to verify that the time to make a
fork call isn't increasing.
Test: Ran benchmarks on walleye and verified that the numbers are not
Test: too variable between runs.
Change-Id: I61d289d277f85ac432a315e539cf6391ea036866
Modules with a libbase dependency also need a liblog dependency now.
Fixes the linker-reloc-bench build target.
Bug: b/147779981
Test: manual
Change-Id: I41dd35717b665524a26a92a0c268e42c93a383b7
The benchmark creates a set of DSOs that mimic the work involved in
loading the current version of libandroid_servers.so. The synthetic
benchmark has roughly the same number of libraries with roughly the same
relocations.
Currently, on a local aosp_walleye build that includes recent performance
improvements (including the Neon-based CL
I3983bca1dddc9241bb70290ad3651d895f046660), using the "performance"
governor, the benchmark reports these scores:
$ adb shell taskset 10 \
/data/benchmarktest64/linker-reloc-bench/linker-reloc-bench \
--benchmark_repetitions=20 --benchmark_display_aggregates_only=true
...
--------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------
BM_linker_relocation/real_time_mean 70048 us 465 us 20
BM_linker_relocation/real_time_median 70091 us 466 us 20
BM_linker_relocation/real_time_stddev 329 us 8.29 us 20
$ adb shell taskset 10 \
/data/benchmarktest/linker-reloc-bench/linker-reloc-bench \
--benchmark_repetitions=20 --benchmark_display_aggregates_only=true
...
--------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------
BM_linker_relocation/real_time_mean 83051 us 462 us 20
BM_linker_relocation/real_time_median 83069 us 464 us 20
BM_linker_relocation/real_time_stddev 184 us 8.91 us 20
Test: manual
Bug: none
Change-Id: I6dac66978f8666f95c76387093bda6be0151bfce
Update the native allocator documentation to include running of this
benchmark.
Move the malloc_benchmark.cpp to malloc_sql_benchmark.cpp and use
malloc_benchmark.cpp for benchmarking functions from malloc.h.
Bug: 137795072
Test: Ran new benchmark.
Change-Id: I76856de833032da324ad0bc0b6bd85a4ea8c253d
Right now, when we read a system property, we first (assuming we've
already looked up the property's prop_info) read the property's serial
number; if we find that the low bit (the dirty bit) in the serial
number is set, we futex-wait for that serial number to become
non-dirty. By doing so, we spare readers from seeing partially-updated
property values if they race with the property service's non-atomic
memcpy to the property value slot. (The futex-wait here isn't
essential to the algorithm: spinning while dirty would suffice,
although it'd be somewhat less efficient.)
The problem with this approach is that readers can wait on the
property service process, potentially causing delays due to scheduling
variance. Property reads are not guaranteed to complete in finite time
right now.
This change makes property reads wait-free and ensures that they
complete in finite time in all cases. In the new approach, we prevent
value tearing by backing up each property we're about to modify and
directing readers to the backup copy if they try to read a property
with the dirty bit set.
(The wait freedom is limited to the case of readers racing against
*one* property update. A writer can still delay readers by rapidly
updating a property --- but after this change, readers can't hang due
to PID 1 scheduling delays.)
I considered adding explicit atomic access to short property values,
but between binary compatibility with the existing property database
and the need to carefully handle transitions of property values
between "short" (compatible with atomics) and "long" (incompatible
with atomics) length domains, I figured the complexity wasn't worth it
and that making property reads wait-free would be adequate.
Test: boots
Bug: 143561649
Change-Id: Ifd3108aedba5a4b157b66af6ca0a4ed084bd5982
Just to sanity check that toupper/tolower and towupper/towlower are in
the same ballpark for the ASCII range.
Test: ran benchmarks
Change-Id: I1ddc3f4f4478b4075107831f27bf4d4b4a3bc5e8
This reverts commit 3bf27c86d1.
Disable the 32-bit glibc target. We're not interested in benchmarking that
target, and the bench_noop_nostl executable doesn't build when ASAN is
turned on, because the libclang_rt.asan_cxx-i386.a lib contains
ubsan_type_hash_itanium.cc.o, which needs __dynamic_cast and various
STL typeinfo variables. The equivalent libclang_rt.asan_cxx-x86_64.a
lib doesn't have ubsan_type_hash_itanium.cc.o in it.
Bug: http://b/141693636
Test: m bench_noop_nostl bench_noop bench_noop_static ASAN_OPTIONS=detect_leaks=0 SANITIZE_HOST=address
Change-Id: Id6de17e622682f3a166367ad670cba5bfa6aee47
Many of our benchmarks are basically just "call one function with a
fixed argument". We don't need to keep repeating all the boilerplate for
that.
This also ensures we don't forget the benchmark::DoNotOptimize, which --
in addition to being a good idea in general -- specifically solves the
problem with gettid benchmark and provides a more accurate result by
removing the indirection through a function pointer.
Test: ran benchmarks
Change-Id: Id67535243678cd0d48f51cf25141e2040da9af03
Specifically, test the wall-clock time for running:
* a C program that does nothing (i.e. no STL)
* a C++ program that does nothing
* a statically-linked C++ program
* toybox true (in /system/bin and /vendor/bin)
* mksh -c true (in /system/bin and /vendor/bin)
Test: bionic-spawn-benchmarks
Change-Id: I961850ec90004cac83088feab5783f4f27768be1
* Fix the path to bionic-benchmarks-glibc
* Add symlinks for the toybox symlink commands. Each symlink bypasses the
intermediate symlink in ${OUT}/system/bin and points to the final
toybox binary. Suppress a bunch of warnings by skipping symlinks for
non-existent files.
The new spawn benchmarks try to run /system/bin/true. (They also try to
run /vendor/bin/true and print an error.)
* Quote "$@"
* Use soong_ui.bash --dumpvars-mode to set a bunch of variables, rather
than get_build_var, which invokes Soong once per variable. This reduces
the "build/run-on-host.sh" runtime from 4s to 1.3s.
* build/run-on-host.sh isn't executable and is only useful when it's
sourced into another shell, so remove its shebang to reduce confusion.
Bug: none
Test: \
. build/envsetup.sh
lunch aosp_x86_64-userdebug
. bionic/build/run-on-host.sh
prepare MODULES-IN-bionic MODULES-IN-external-toybox
/system/bin/true
Change-Id: I59e9a6aca77d35b16bdf51759c5fc7e725bfc67c
This was broken by all the mainline modules stuff. It's quite a bit
hairier to set up now, given that we don't have an apexd on the host.
An alternative might be to actually set up a fake /apex that points to
the bootstrap directories?
Test: ./benchmarks/run-on-host.sh 64
Test: ./tests/run-on-host.sh 64
Change-Id: If2c277ba492c7c443cdf51526ea42f56568e2ea6
Adding some benchmarks that keep a certain number of allocation
around. This benchmark should not be used as an absolute for determining
what is a good/bad native allocator. However, it should be used to make
sure that numbers are not completely changed between allocator versions.
Also update the malloc sql benchmark to match the same style as these
new benchmarks.
Bug: 129743239
Test: Ran these benchmarks.
Change-Id: I1995d98fd269b61d9c96efed6eff3ed278e24c97
