From 39b3bfcfffe2c0d88cf37e3d6ed4be14cd256876 Mon Sep 17 00:00:00 2001
From: Adam Michalski <a.michalski2@partner.samsung.com>
Date: Thu, 27 Jan 2022 17:31:17 +0100
Subject: [PATCH] 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
---
 benchmark/dbus-tools-batch-tests.sh | 37 ++++++++++++++++++++++++-----
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/benchmark/dbus-tools-batch-tests.sh b/benchmark/dbus-tools-batch-tests.sh
index f432689..94ad0ea 100755
--- 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
-- 
2.34.1