Message ID | 20211028143327.hfbxjze7palrpfgp@linutronix.de (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT | expand |
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>
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>
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
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
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(-)