[PATCH] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT

[PATCH] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT

[Sebastian Andrzej Siewior]

TRANSPARENT_HUGEPAGE:
There are potential non-deterministic delays to an RT thread if a critical
memory region is not THP-aligned and a non-RT buffer is located in the same
hugepage-aligned region. It's also possible for an unrelated thread to migrate
pages belonging to an RT task incurring unexpected page faults due to memory
defragmentation even if khugepaged is disabled.

Regular HUGEPAGEs are not affected by this can be used.

NUMA_BALANCING:
There is a non-deterministic delay to mark PTEs PROT_NONE to gather NUMA fault
samples, increased page faults of regions even if mlocked and non-deterministic
delays when migrating pages.

[Mel Gorman worded 99% of the commit description].

Link: https://lore.kernel.org/all/20200304091159.GN3818@techsingularity.net/
Link: https://lore.kernel.org/all/20211026165100.ahz5bkx44lrrw5pt@linutronix.de/
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 init/Kconfig | 2 +-
 mm/Kconfig   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index edc0a0228f143..f83e7a0478f7c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -911,7 +911,7 @@ config NUMA_BALANCING
 	bool "Memory placement aware NUMA scheduler"
 	depends on ARCH_SUPPORTS_NUMA_BALANCING
 	depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
-	depends on SMP && NUMA && MIGRATION
+	depends on SMP && NUMA && MIGRATION && !PREEMPT_RT
 	help
 	  This option adds support for automatic NUMA aware memory/task placement.
 	  The mechanism is quite primitive and is based on migrating memory when
diff --git a/mm/Kconfig b/mm/Kconfig
index c150a0c6fce2c..5c5508fafcec5 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -374,7 +374,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
 
 config TRANSPARENT_HUGEPAGE
 	bool "Transparent Hugepage Support"
-	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
+	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT
 	select COMPACTION
 	select XARRAY_MULTI
 	help
-- 
2.33.1

Re: [PATCH] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT

[Mel Gorman]

On Thu, Oct 28, 2021 at 04:33:27PM +0200, Sebastian Andrzej Siewior wrote:
> TRANSPARENT_HUGEPAGE:
> There are potential non-deterministic delays to an RT thread if a critical
> memory region is not THP-aligned and a non-RT buffer is located in the same
> hugepage-aligned region. It's also possible for an unrelated thread to migrate
> pages belonging to an RT task incurring unexpected page faults due to memory
> defragmentation even if khugepaged is disabled.
> 
> Regular HUGEPAGEs are not affected by this can be used.
> 
> NUMA_BALANCING:
> There is a non-deterministic delay to mark PTEs PROT_NONE to gather NUMA fault
> samples, increased page faults of regions even if mlocked and non-deterministic
> delays when migrating pages.
> 
> [Mel Gorman worded 99% of the commit description].
> 
> Link: https://lore.kernel.org/all/20200304091159.GN3818@techsingularity.net/
> Link: https://lore.kernel.org/all/20211026165100.ahz5bkx44lrrw5pt@linutronix.de/
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

Acked-by: Mel Gorman <mgorman@techsingularity.net>

-- 
Mel Gorman
SUSE Labs

Re: [PATCH] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT

[David Hildenbrand]

On 28.10.21 16:33, Sebastian Andrzej Siewior wrote:
> TRANSPARENT_HUGEPAGE:
> There are potential non-deterministic delays to an RT thread if a critical
> memory region is not THP-aligned and a non-RT buffer is located in the same
> hugepage-aligned region. It's also possible for an unrelated thread to migrate
> pages belonging to an RT task incurring unexpected page faults due to memory
> defragmentation even if khugepaged is disabled.
> 
> Regular HUGEPAGEs are not affected by this can be used.
> 
> NUMA_BALANCING:
> There is a non-deterministic delay to mark PTEs PROT_NONE to gather NUMA fault
> samples, increased page faults of regions even if mlocked and non-deterministic
> delays when migrating pages.
> 
> [Mel Gorman worded 99% of the commit description].
> 
> Link: https://lore.kernel.org/all/20200304091159.GN3818@techsingularity.net/
> Link: https://lore.kernel.org/all/20211026165100.ahz5bkx44lrrw5pt@linutronix.de/
> Cc: Mel Gorman <mgorman@techsingularity.net>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  init/Kconfig | 2 +-
>  mm/Kconfig   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index edc0a0228f143..f83e7a0478f7c 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -911,7 +911,7 @@ config NUMA_BALANCING
>  	bool "Memory placement aware NUMA scheduler"
>  	depends on ARCH_SUPPORTS_NUMA_BALANCING
>  	depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
> -	depends on SMP && NUMA && MIGRATION
> +	depends on SMP && NUMA && MIGRATION && !PREEMPT_RT
>  	help
>  	  This option adds support for automatic NUMA aware memory/task placement.
>  	  The mechanism is quite primitive and is based on migrating memory when
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c150a0c6fce2c..5c5508fafcec5 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -374,7 +374,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
>  
>  config TRANSPARENT_HUGEPAGE
>  	bool "Transparent Hugepage Support"
> -	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
> +	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT
>  	select COMPACTION
>  	select XARRAY_MULTI
>  	help
> 

Makes perfect sense to me. I was also wondering how "dangerous"
MIGRATION (and everything depending on it, like CMA, compaction,
MEMORY_HOTREMOVE, ...) is for RT recently.

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb

Re: [PATCH] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT

[Sebastian Andrzej Siewior]

On 2021-10-28 17:54:01 [+0200], David Hildenbrand wrote:
> Makes perfect sense to me. I was also wondering how "dangerous"
> MIGRATION (and everything depending on it, like CMA, compaction,
> MEMORY_HOTREMOVE, ...) is for RT recently.

for compatcion there is
  6923aa0d8c629 ("mm/compaction: Disable compact_unevictable_allowed on RT")

to honour mlock() otherwise it can end unpleasant. But yeah, any page
migrations outside of the "setup/ init" phase of the RT task are bad.

Sebastian