[DTrace-devel] [PATCH 7/7] test: Update tst.aggmod_full2.sh

eugene.loh at oracle.com eugene.loh at oracle.com
Tue Mar 12 01:00:57 UTC 2024


From: Eugene Loh <eugene.loh at oracle.com>

Remove the xfail now that duplicate mod() keys have been reduced to
unique values.

Also, update the test to handle the large number of addresses passed
from producer to consumer.  In DTrace, @[mod(addr)] is handled by
passing individual addresses to the consumer, which is responsible
for reducing to unique mod() values.  This test marches through all
symbols found in /proc/kall[mod]syms and might therefore pass close
to 200k addresses.  In legacy DTrace, this was handled with aggrate
and throttling the trigger program.  These techniques do not work in
the DTrace on Linux port, which keeps building the BPF aggregation
maps.  So, remove the throttle and expand aggsize.  Also, reduce
strsize to alleviate the pressure on aggsize.

Finally, ignore the problematic __builtin__ftrace module.

Signed-off-by: Eugene Loh <eugene.loh at oracle.com>
---
 test/unittest/aggs/tst.aggmod_full2.sh | 33 +++++++++++++-------------
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/test/unittest/aggs/tst.aggmod_full2.sh b/test/unittest/aggs/tst.aggmod_full2.sh
index 2ae5a28c..100eb561 100755
--- a/test/unittest/aggs/tst.aggmod_full2.sh
+++ b/test/unittest/aggs/tst.aggmod_full2.sh
@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 # Oracle Linux DTrace.
-# Copyright (c) 2018, 2021, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2018, 2024, Oracle and/or its affiliates. All rights reserved.
 # Licensed under the Universal Permissive License v 1.0 as shown at
 # http://oss.oracle.com/licenses/upl.
 #
@@ -16,8 +16,6 @@
 #
 ##
 
-# @@xfail: dtv2
-
 dtrace=$1
 CC=/usr/bin/gcc
 CFLAGS=
@@ -39,7 +37,6 @@ cat > test.c << EOF
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <unistd.h>
 #include <linux/limits.h>
 #include <time.h>
 #include "prov.h"
@@ -62,7 +59,6 @@ int main(int argc, char **argv) {
 		char type;
 		char symname[KSYM_NAME_MAX];
 		char modname[PATH_MAX] = "vmlinux]";
-		struct timespec throttle;
 
 		/* read the symbol */
 		if (sscanf(line, "%llx %llx %c %s [%s",
@@ -94,18 +90,14 @@ int main(int argc, char **argv) {
 		if (strcmp(modname, "bpf]") == 0)
 			continue;
 
+		/* we cannot dt_module_load("__builtin__ftrace") */
+		if (strcmp(modname, "__builtin__ftrace]") == 0)
+			continue;
+
 		/* trim the trailing ']' and print modname to stdout */
 		modname[strlen(modname)-1] = '\0';
 		printf("%s\n", modname);
 
-		/* throttle a little so that both:
-		 * - data is not dropped
-		 * - 100k symbols still only take seconds to run
-		 */
-		throttle.tv_sec = 0;
-		throttle.tv_nsec = 1000;
-		nanosleep(&throttle, NULL);
-
 		/* pass (addr,modname) to the static probe */
 		TEST_PROV_AGGMODTEST(addr, modname);
 	}
@@ -171,10 +163,17 @@ fi
 #     and save in modules.txt for comparison with output.txt
 # ==================================================
 
-$dtrace $dt_flags -c ./a.out -o output.txt -s /dev/stdin << EOF \
+# The aggregation keys are:
+#   - an 8-byte address
+#   - a mod name, which should fit into strsize=48
+# With the aggregation # value, that's about 64 bytes per entry.
+# If /proc/kall[mod]syms has fewer than 200k symbols we care about,
+# all that should fit into an aggsize of 16M.
+# If this aggsize becomes a problem, we can do something fancy like
+# having the trigger bounce among CPUs.  Then the (per-CPU) aggsize
+# could be reduced.
+$dtrace $dt_flags -xstrsize=48 -xaggsize=16m -c ./a.out -o output.txt -s /dev/stdin << EOF \
     2> errors.txt | sort | uniq -c | awk '{print $1, $2}' > modules.txt
-#pragma D option aggrate=50hz
-
 test_prov\$target:::
 {
 	@[mod(arg0), copyinstr(arg1)] = count();
@@ -188,7 +187,7 @@ fi
 if [[ `grep -c "aggregation drops on CPU" errors.txt` -gt 0 ]]; then
 	echo
 	grep "aggregation drops on CPU" errors.txt
-	echo "$tst: might need a larger value of throttle.tv_nsec"
+	echo "$tst: might need a larger value of aggsize"
 	echo
 	exit 1
 fi
-- 
2.18.4




More information about the DTrace-devel mailing list