[PATCH] selftests/mm: skip migration tests if NUMA is unavailable

AnishMulay posted 1 patch 1 month, 1 week ago
tools/testing/selftests/mm/migration.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
[PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by AnishMulay 1 month, 1 week ago
Currently, the migration test asserts that numa_available() returns 0.
On systems where NUMA is not available (returning -1), such as certain
ARM64 configurations or single-node systems, this assertion fails and
crashes the test.

Update the test to check the return value of numa_available(). If it
is less than 0, skip the test gracefully instead of failing.

This aligns the behavior with other MM selftests (like rmap) that
skip when NUMA support is missing.

Signed-off-by: AnishMulay <anishm7030@gmail.com>
---
 tools/testing/selftests/mm/migration.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mm/migration.c b/tools/testing/selftests/mm/migration.c
index ee24b88c2b248..60e78bbfc0e3e 100644
--- a/tools/testing/selftests/mm/migration.c
+++ b/tools/testing/selftests/mm/migration.c
@@ -36,7 +36,8 @@ FIXTURE_SETUP(migration)
 {
 	int n;
 
-	ASSERT_EQ(numa_available(), 0);
+	if (numa_available() < 0)
+		SKIP(return, "NUMA not available");
 	self->nthreads = numa_num_task_cpus() - 1;
 	self->n1 = -1;
 	self->n2 = -1;
-- 
2.51.0
Re: [PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by David Hildenbrand (Arm) 1 month, 1 week ago
On 2/18/26 17:39, AnishMulay wrote:
> Currently, the migration test asserts that numa_available() returns 0.
> On systems where NUMA is not available (returning -1), such as certain
> ARM64 configurations or single-node systems, this assertion fails and
> crashes the test.

Single-node system (my notebook)

$ ./migration
TAP version 13
1..6
# Starting 6 tests from 1 test cases.
#  RUN           migration.private_anon ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.private_anon
ok 1 migration.private_anon # SKIP Not enough threads or NUMA nodes 
available
#  RUN           migration.shared_anon ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.shared_anon
ok 2 migration.shared_anon # SKIP Not enough threads or NUMA nodes available
#  RUN           migration.private_anon_thp ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.private_anon_thp
ok 3 migration.private_anon_thp # SKIP Not enough threads or NUMA nodes 
available
#  RUN           migration.shared_anon_thp ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.shared_anon_thp
ok 4 migration.shared_anon_thp # SKIP Not enough threads or NUMA nodes 
available
#  RUN           migration.private_anon_htlb ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.private_anon_htlb
ok 5 migration.private_anon_htlb # SKIP Not enough threads or NUMA nodes 
available
#  RUN           migration.shared_anon_htlb ...
#      SKIP      Not enough threads or NUMA nodes available
#            OK  migration.shared_anon_htlb
ok 6 migration.shared_anon_htlb # SKIP Not enough threads or NUMA nodes 
available
# PASSED: 6 / 6 tests passed.
# 6 skipped test(s) detected. Consider enabling relevant config options 
to improve coverage.
# Totals: pass:0 fail:0 xfail:0 xpass:0 skip:6 error:0


What numa_available() really checks is if the kernel supports NUMA by 
trying get_mempolicy(). If that fails with ENOSYS or EPERM.

That should mostly (cases we care about) be the case if the kernel is 
compiled without CONFIG_NUMA.

So a better description here would be "On kernels without CONFIG_NUMA, 
this assertion ..."

Given that tools/testing/selftests/mm/config does not include 
CONFIG_NUMA, I think we want to add here

Fixes: 0c2d08728470b ("mm: add selftests for migration entries")

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David
Re: [PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by Sayali Patil 1 month, 1 week ago
Hi Anish,

On 18/02/26 22:09, AnishMulay wrote:
> Currently, the migration test asserts that numa_available() returns 0.
> On systems where NUMA is not available (returning -1), such as certain
> ARM64 configurations or single-node systems, this assertion fails and
> crashes the test.
>
> Update the test to check the return value of numa_available(). If it
> is less than 0, skip the test gracefully instead of failing.
>
> This aligns the behavior with other MM selftests (like rmap) that
> skip when NUMA support is missing.
>
> Signed-off-by: AnishMulay <anishm7030@gmail.com>
I tested it on my system and its skipping the test if NUMA not available.

TAP version 13
1..6
# Starting 6 tests from 1 test cases.
#  RUN           migration.private_anon ...
#      SKIP      NUMA not available
#            OK  migration.private_anon
ok 1 migration.private_anon # SKIP NUMA not available
#  RUN           migration.shared_anon ...
#      SKIP      NUMA not available
#            OK  migration.shared_anon
ok 2 migration.shared_anon # SKIP NUMA not available
#  RUN           migration.private_anon_thp ...
#      SKIP      NUMA not available
#            OK  migration.private_anon_thp
ok 3 migration.private_anon_thp # SKIP NUMA not available
#  RUN           migration.shared_anon_thp ...
#      SKIP      NUMA not available
#            OK  migration.shared_anon_thp
ok 4 migration.shared_anon_thp # SKIP NUMA not available
#  RUN           migration.private_anon_htlb ...
#      SKIP      NUMA not available
#            OK  migration.private_anon_htlb
ok 5 migration.private_anon_htlb # SKIP NUMA not available
#  RUN           migration.shared_anon_htlb ...
#      SKIP      NUMA not available
#            OK  migration.shared_anon_htlb
ok 6 migration.shared_anon_htlb # SKIP NUMA not available
# PASSED: 6 / 6 tests passed.
# 6 skipped test(s) detected. Consider enabling relevant config options 
to improve c
overage.
# Totals: pass:0 fail:0 xfail:0 xpass:0 skip:6 error:0

Tested-by: Sayali Patil <sayalip@linux.ibm.com>

Thanks,
Sayali

> ---
>   tools/testing/selftests/mm/migration.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/mm/migration.c b/tools/testing/selftests/mm/migration.c
> index ee24b88c2b248..60e78bbfc0e3e 100644
> --- a/tools/testing/selftests/mm/migration.c
> +++ b/tools/testing/selftests/mm/migration.c
> @@ -36,7 +36,8 @@ FIXTURE_SETUP(migration)
>   {
>   	int n;
>   
> -	ASSERT_EQ(numa_available(), 0);
> +	if (numa_available() < 0)
> +		SKIP(return, "NUMA not available");
>   	self->nthreads = numa_num_task_cpus() - 1;
>   	self->n1 = -1;
>   	self->n2 = -1;
Re: [PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by Anshuman Khandual 1 month, 1 week ago

On 18/02/26 10:09 PM, AnishMulay wrote:
> Currently, the migration test asserts that numa_available() returns 0.
> On systems where NUMA is not available (returning -1), such as certain
> ARM64 configurations or single-node systems, this assertion fails and
> crashes the test.
> 
> Update the test to check the return value of numa_available(). If it
> is less than 0, skip the test gracefully instead of failing.
> 
> This aligns the behavior with other MM selftests (like rmap) that
> skip when NUMA support is missing.
> 
> Signed-off-by: AnishMulay <anishm7030@gmail.com>
> ---
>  tools/testing/selftests/mm/migration.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/mm/migration.c b/tools/testing/selftests/mm/migration.c
> index ee24b88c2b248..60e78bbfc0e3e 100644
> --- a/tools/testing/selftests/mm/migration.c
> +++ b/tools/testing/selftests/mm/migration.c
> @@ -36,7 +36,8 @@ FIXTURE_SETUP(migration)
>  {
>  	int n;
>  
> -	ASSERT_EQ(numa_available(), 0);
> +	if (numa_available() < 0)
> +		SKIP(return, "NUMA not available");
>  	self->nthreads = numa_num_task_cpus() - 1;
>  	self->n1 = -1;
>  	self->n2 = -1;

Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Re: [PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by Dev Jain 1 month, 1 week ago
On 18/02/26 10:09 pm, AnishMulay wrote:
> Currently, the migration test asserts that numa_available() returns 0.
> On systems where NUMA is not available (returning -1), such as certain
> ARM64 configurations or single-node systems, this assertion fails and
> crashes the test.
>
> Update the test to check the return value of numa_available(). If it
> is less than 0, skip the test gracefully instead of failing.
>
> This aligns the behavior with other MM selftests (like rmap) that
> skip when NUMA support is missing.
>
> Signed-off-by: AnishMulay <anishm7030@gmail.com>
> ---

Reviewed-by: Dev Jain <dev.jain@arm.com>

>  tools/testing/selftests/mm/migration.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/mm/migration.c b/tools/testing/selftests/mm/migration.c
> index ee24b88c2b248..60e78bbfc0e3e 100644
> --- a/tools/testing/selftests/mm/migration.c
> +++ b/tools/testing/selftests/mm/migration.c
> @@ -36,7 +36,8 @@ FIXTURE_SETUP(migration)
>  {
>  	int n;
>  
> -	ASSERT_EQ(numa_available(), 0);
> +	if (numa_available() < 0)
> +		SKIP(return, "NUMA not available");
>  	self->nthreads = numa_num_task_cpus() - 1;
>  	self->n1 = -1;
>  	self->n2 = -1;
Re: [PATCH] selftests/mm: skip migration tests if NUMA is unavailable
Posted by SeongJae Park 1 month, 1 week ago
On Wed, 18 Feb 2026 11:39:41 -0500 AnishMulay <anishm7030@gmail.com> wrote:

> Currently, the migration test asserts that numa_available() returns 0.
> On systems where NUMA is not available (returning -1), such as certain
> ARM64 configurations or single-node systems, this assertion fails and
> crashes the test.
> 
> Update the test to check the return value of numa_available(). If it
> is less than 0, skip the test gracefully instead of failing.
> 
> This aligns the behavior with other MM selftests (like rmap) that
> skip when NUMA support is missing.
> 
> Signed-off-by: AnishMulay <anishm7030@gmail.com>

Reviewed-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]