All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT
Date: Thu, 28 Oct 2021 15:14:52 +0100	[thread overview]
Message-ID: <20211028141451.GT3959@techsingularity.net> (raw)
In-Reply-To: <20211028135647.k6bdwbpxn5sdle5k@linutronix.de>

On Thu, Oct 28, 2021 at 03:56:47PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-28 13:52:24 [+0100], Mel Gorman wrote:
> > > Yes that was my question. So if you have "always", do mlock_all() in the
> > > application and then have other threads that same application doing
> > > malloc/ free of memory that the RT thread is not touching then bad
> > > things can still happen, right?
> > > My understanding is that all threads can be blocked in a page fault if
> > > there is some THP operation going on.
> > > 
> > 
> > Hmm, it could happen if all the memory used by the RT thread was not
> > hugepage-aligned and potentially khugepaged could interfere. khugepaged
> > can be disabled if tuned properly but the alignment requirement would be
> > tricky. Probably safer to just disable it like it has been historically.
> > For consistently, force NUMA_BALANCING to be disabled too because it
> > introduces non-deterministic latencies even if memory regions are locked
> > and bound.
> 
> Okay. I don't mind disabling it or keeping it enabled under some
> restrictions. I just need it to document it so people are aware why it
> is disabled so if they want to enable they know what the areas that need
> attention.
> 
> THP disable due to alignment issues and potential defragmentation by
> khugepaged. Understood. Workaround: Use hugepages.
> 
> NUMA_BALANCING. It looks like it replaces the physical page while
> keeping the virtual address. This kind of page migration does not look
> good if it happens for everyone since it involves mmap_lock.
> Let me write that up and post properly.
> 

In case it helps;

TRANSPARENT_HUGEPAGE: There are potential non-determinstic 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.

NUMA_BALANCING: There is a non-determinstic 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
SUSE Labs


  reply	other threads:[~2021-10-28 14:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 16:51 [RFC] mm: Disable NUMA_BALANCING_DEFAULT_ENABLED and TRANSPARENT_HUGEPAGE on PREEMPT_RT Sebastian Andrzej Siewior
2021-10-27  9:12 ` Mel Gorman
2021-10-28 12:04   ` Sebastian Andrzej Siewior
2021-10-28 12:52     ` Mel Gorman
2021-10-28 13:56       ` Sebastian Andrzej Siewior
2021-10-28 14:14         ` Mel Gorman [this message]
2021-10-28 14:34           ` Sebastian Andrzej Siewior

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=20211028141451.GT3959@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    /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.