diff mbox series

test/lcores: reduce cpu consumption

Message ID 20240307113324.845309-1-david.marchand@redhat.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series test/lcores: reduce cpu consumption |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/github-robot: build fail github build: failed
ci/intel-Functional success Functional PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-compile-amd64-testing fail Testing issues
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-unit-amd64-testing fail Testing issues
ci/iol-sample-apps-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS

Commit Message

David Marchand March 7, 2024, 11:33 a.m. UTC 
  Busy looping on RTE_MAX_LCORES threads is too heavy in some CI
environments running the fast-test testsuite.
Ask for a reschedule at the threads synchronisation points.

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Note: this is a quick patch with no validation, except that it runs fine
on my laptop.
Luca, can you check and see if it helps in your CI?

---
 app/test/test_lcores.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Comments

Luca Boccassi March 7, 2024, 12:09 p.m. UTC | #1 
On Thu, 7 Mar 2024 at 11:33, David Marchand <david.marchand@redhat.com> wrote:
>
> Busy looping on RTE_MAX_LCORES threads is too heavy in some CI
> environments running the fast-test testsuite.
> Ask for a reschedule at the threads synchronisation points.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Note: this is a quick patch with no validation, except that it runs fine
> on my laptop.
> Luca, can you check and see if it helps in your CI?

I hit problems in the actual build system, rather than in a CI, so I
don't have a way to test it before doing a new release. That said, the
change looks good to me in principle and we can certainly try it,
thanks.

Acked-by: Luca Boccassi <bluca@debian.org>
Stephen Hemminger March 7, 2024, 4:54 p.m. UTC | #2 
On Thu,  7 Mar 2024 12:33:24 +0100
David Marchand <david.marchand@redhat.com> wrote:

> Busy looping on RTE_MAX_LCORES threads is too heavy in some CI
> environments running the fast-test testsuite.
> Ask for a reschedule at the threads synchronisation points.
> 
> Signed-off-by: David Marchand <david.marchand@redhat.com>

You could use rte_pause here but full yield is better for test cases.

Acked-by: Stephen Hemminger <stephen@networkplumber.org>
diff mbox series

Patch

diff --git a/app/test/test_lcores.c b/app/test/test_lcores.c
index 22225a9fd3..7adc03d3da 100644
--- a/app/test/test_lcores.c
+++ b/app/test/test_lcores.c
@@ -2,6 +2,7 @@ 
  * Copyright (c) 2020 Red Hat, Inc.
  */
 
+#include <sched.h>
 #include <string.h>
 
 #include <rte_common.h>
@@ -43,7 +44,7 @@  static uint32_t thread_loop(void *arg)
 
 	/* Wait for release from the control thread. */
 	while (__atomic_load_n(t->registered_count, __ATOMIC_ACQUIRE) != 0)
-		;
+		sched_yield();
 	rte_thread_unregister();
 	lcore_id = rte_lcore_id();
 	if (lcore_id != LCORE_ID_ANY) {
@@ -85,7 +86,7 @@  test_non_eal_lcores(unsigned int eal_threads_count)
 	/* Wait all non-EAL threads to register. */
 	while (__atomic_load_n(&registered_count, __ATOMIC_ACQUIRE) !=
 			non_eal_threads_count)
-		;
+		sched_yield();
 
 	/* We managed to create the max number of threads, let's try to create
 	 * one more. This will allow one more check.
@@ -101,7 +102,7 @@  test_non_eal_lcores(unsigned int eal_threads_count)
 		printf("non-EAL threads count: %u\n", non_eal_threads_count);
 		while (__atomic_load_n(&registered_count, __ATOMIC_ACQUIRE) !=
 				non_eal_threads_count)
-			;
+			sched_yield();
 	}
 
 skip_lcore_any:
@@ -267,7 +268,7 @@  test_non_eal_lcores_callback(unsigned int eal_threads_count)
 	non_eal_threads_count++;
 	while (__atomic_load_n(&registered_count, __ATOMIC_ACQUIRE) !=
 			non_eal_threads_count)
-		;
+		sched_yield();
 	if (l[0].init != eal_threads_count + 1 ||
 			l[1].init != eal_threads_count + 1) {
 		printf("Error: incorrect init calls, expected %u, %u, got %u, %u\n",
@@ -290,7 +291,7 @@  test_non_eal_lcores_callback(unsigned int eal_threads_count)
 	non_eal_threads_count++;
 	while (__atomic_load_n(&registered_count, __ATOMIC_ACQUIRE) !=
 			non_eal_threads_count)
-		;
+		sched_yield();
 	if (l[0].init != eal_threads_count + 2 ||
 			l[1].init != eal_threads_count + 2) {
 		printf("Error: incorrect init calls, expected %u, %u, got %u, %u\n",