Improve batch tests runner script

The following improvements have been incorporated:
- tweaked hackbench invocation by reducing the number of processes to 72
which is arbitrary but enough to generate a load of 25-30 that better
mimics the real working environment of a heavily loaded system
- parametrized calculating delays between sent messages depending on
the message size for libdbus peer to peer to make it consistent with
other IPC tests.

Change-Id: I5b4da9571286ee87f5a06374d75739a97427b870

diff --git a/benchmark/dbus-tools-batch-tests.sh b/benchmark/dbus-tools-batch-tests.sh
index f432689c9dbae92366c3ba40c18ccafa32d96841..94ad0eaa5e627c687d19572eb3e54ec287d57d1d 100755 (executable)
--- a/benchmark/dbus-tools-batch-tests.sh
+++ b/benchmark/dbus-tools-batch-tests.sh
@@ -16,6 +16,10 @@ SMALL_MSG_SIZE=32
 # reasonable distribution graph of the latency values.
 REAL_TRIES=100000
 
+# OS-dependent constant used for calculating delays between sent messages.
+# Borrowed from the source code of the IPC tests for consistency.
+readonly ONE_PAGE_SIZE=4096
+
 run_ipc_tests() {
        if [ ! -d $1 ]; then
                if mkdir $1; then
@@ -35,7 +39,25 @@ run_ipc_tests() {
        # a heavily loaded system.
        sleep 10
        LIBDBUS_P2P_TRY_COUNT=`expr $3 + 1000`
-       libdbus-p2p-client -m $2 -t $LIBDBUS_P2P_TRY_COUNT -d 50
+
+       # The following piece of code, that sets the value of the
+       # `LIBDBUS_P2P_TRY_COUNT` variable, is an exact reflection of the same
+       # code snippet found in the other IPC tests. It sets the delay between
+       # sent messages to prevent latencies from stacking.
+       # The reason why this is here is that it's parametrized in the libdbus
+       # p2p test, while in other IPC tests it's hard-coded.
+
+       if [ "$2" -le "$ONE_PAGE_SIZE" ]; then
+               LIBDBUS_P2P_DELAY=5000;
+       elif [ "$2" -le `expr 10 \* $ONE_PAGE_SIZE` ]; then
+               LIBDBUS_P2P_DELAY=10000;
+       elif [ "$2" -le `expr 100 \* $ONE_PAGE_SIZE` ]; then
+               LIBDBUS_P2P_DELAY=20000;
+       else
+               LIBDBUS_P2P_DELAY=40000;
+       fi
+
+       libdbus-p2p-client -m $2 -t $LIBDBUS_P2P_TRY_COUNT -d $LIBDBUS_P2P_DELAY
        pipe -m $2 -l -r -t $3
        socket -m $2 -l -r -t $3
        sharedmem -m $2 -l -r -t $3
@@ -83,15 +105,18 @@ fi
 
 # tests under heavy load
 
-# hackbench produces 40 processes times the value,
-# the resulting 560 processes is arbitrary but "a lot"
-readonly PROCESS_COUNT=14
+# hackbench produces #groups times #file descriptors times 2 processes.
+# The resulting 72 processes is arbitrary but enough to generate a load of
+# about 25-30 on x64 and RPi4. This mimics the real working environment of
+# a heavily loaded system.
+readonly GROUPS_COUNT=6
+readonly FILE_DESC_COUNT=6
 
 # enough messages to keep the rest of the system busy
 # throughout the entire dbus test
-readonly MESSAGE_COUNT=9900000
+readonly MESSAGE_COUNT=1000000000
 
-hackbench --pipe --groups $PROCESS_COUNT --loops $MESSAGE_COUNT &
+hackbench --pipe --groups $GROUPS_COUNT --fds $FILE_DESC_COUNT --loops $MESSAGE_COUNT &
 HACKBENCH_PID=$!
 
 run_ipc_tests load_small $SMALL_MSG_SIZE $REAL_TRIES