All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mat Martineau <mathew.j.martineau@linux.intel.com>
To: mptcp@lists.linux.dev
Cc: Mat Martineau <mathew.j.martineau@linux.intel.com>, pabeni@redhat.com
Subject: [PATCH mptcp-next] Squash-to: "selftests: mptcp: tweak simult_flows for debug kernels"
Date: Mon, 27 Jun 2022 14:44:38 -0700	[thread overview]
Message-ID: <20220627214438.17887-1-mathew.j.martineau@linux.intel.com> (raw)

kbuild is still seeing intermittent failures in the simult_flows.sh
test. It uses a kernel config without kmemleak, but with other
performance-affecting debug options like lockdep and kasan.

Example failures:
kernel-selftests.net/mptcp.simult_flows.sh.unbalanced_bwidth_with_unbalanced_delay_transfer_slower_than_expected!_runtime_4339_ms_expected_4005_ms_max_4005.fail
kernel-selftests.net/mptcp.simult_flows.sh.unbalanced_bwidth_transfer_slower_than_expected!_runtime_4285_ms_expected_4005_ms_max_4005.fail
kernel-selftests.net/mptcp.simult_flows.sh.unbalanced_bwidth_transfer_slower_than_expected!_runtime_4346_ms_expected_4005_ms_max_4005.fail

Adjust the debug detection to loosen the simult_flows timing constraints
if either kmemleak or lockdep are configured.

Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
---
 tools/testing/selftests/net/mptcp/simult_flows.sh | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
index e266b26a4274..fa4f0bf55049 100755
--- a/tools/testing/selftests/net/mptcp/simult_flows.sh
+++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
@@ -110,9 +110,10 @@ setup()
 	# debug build can slow down measurably the test program
 	# we use quite tight time limit on the run-time, to ensure
 	# maximum B/W usage.
-	# Use the kmemleak file presence as a rough estimate for this being
-	# a debug kernel and increase the maximum run-time accordingly
-	[ -f /sys/kernel/debug/kmemleak ] && slack=$((slack+200))
+	# Use the kmemleak or lockdep file presence as a rough estimate
+	# for this being a debug kernel and increase the maximum
+	# run-time accordingly
+	[ -f /sys/kernel/debug/kmemleak -o -f /proc/lockdep ] && slack=$((slack+200))
 }
 
 # $1: ns, $2: port
-- 
2.36.1


             reply	other threads:[~2022-06-27 21:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 21:44 Mat Martineau [this message]
2022-06-27 23:11 ` Squash-to: "selftests: mptcp: tweak simult_flows for debug kernels": Tests Results MPTCP CI
2022-06-28  9:42 ` [PATCH mptcp-next] Squash-to: "selftests: mptcp: tweak simult_flows for debug kernels" Matthieu Baerts
2022-06-28 17:55   ` Mat Martineau
2022-06-29  8:32     ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220627214438.17887-1-mathew.j.martineau@linux.intel.com \
    --to=mathew.j.martineau@linux.intel.com \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.