All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Iurii Zaikin <yzaikin@google.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mm/compaction: Disable compact_unevictable_allowed on RT
Date: Thu, 16 Jan 2020 11:22:39 +0100	[thread overview]
Message-ID: <20200116102239.m2trw3cvosn7q5a5@linutronix.de> (raw)
In-Reply-To: <4cf4507b-0632-34e6-5985-df933559af9f@suse.cz>

On 2020-01-15 23:04:19 [+0100], Vlastimil Babka wrote:
> On 1/15/2020 5:10 PM, Sebastian Andrzej Siewior wrote:
> > Since commit
> >     5bbe3547aa3ba ("mm: allow compaction of unevictable pages")
> > 
> > it is allowed to examine mlocked pages and compact them by default.
> > On -RT even minor pagefaults are problematic because it may take a few
> > 100us to resolve them and until then the task is blocked.
> 
> Fine, this makes sense on RT I guess. There might be some trade-off for
> high-order allocation latencies though. We could perhaps migrate such mlocked
> pages to pages allocated without __GFP_MOVABLE during the mlock() to at least
> somewhat prevent them being scattered all over the zones. For MCL_FUTURE,
> allocate them as unmovable from the beginning. But that can wait until issues
> are reported.
> I assume you have similar solution for NUMA balancing and whatever else can
> cause minor faults?

I've found this one while testing. Could you please point to the NUMA
balancing that might be an issue?

> > Make compact_unevictable_allowed = 0 default and remove it from /proc on
> > RT.
> 
> Removing it is maybe going too far in terms of RT kernel differences confusing
> users? Change the default sure, perhaps making it read-only, but removing?

Okay. I will make it RO then. 

> > Link: https://lore.kernel.org/linux-mm/20190710144138.qyn4tuttdq6h7kqx@linutronix.de/
> 
> In any case the sysctl Documentation/ should be updated? And perhaps also the
> mlock manpage as you noted in the older thread above?

Sure. Let me add the sysctl documentation to this patch and then I will
look into the manpage.

> Thanks,
> Vlastimil

Sebastian

  reply	other threads:[~2020-01-16 10:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 16:10 [PATCH] mm/compaction: Disable compact_unevictable_allowed on RT Sebastian Andrzej Siewior
     [not found] ` <20200115161035.893221-1-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2020-01-15 22:04   ` Vlastimil Babka
2020-01-15 22:04     ` Vlastimil Babka
2020-01-16 10:22     ` Sebastian Andrzej Siewior [this message]
2020-03-02 17:35     ` [PATCH v2] " Sebastian Andrzej Siewior
2020-03-02 21:25       ` Andrew Morton
2020-03-03 17:59         ` Sebastian Andrzej Siewior
2020-03-03 20:20           ` [PATCH 1/2] =?UTF-8?q?mm/compaction:=20Really=20limit=20compact?= =?UTF-8?q?=5Funevictable=5Fallowed=20to=200=E2=80=A61?= Sebastian Andrzej Siewior
2020-03-03 20:22             ` [PATCH 2/2 v3] mm/compaction: Disable compact_unevictable_allowed on RT Sebastian Andrzej Siewior
2020-03-03 23:56               ` Andrew Morton
2020-03-04  8:19                 ` Vlastimil Babka
2020-03-04  9:27                   ` Sebastian Andrzej Siewior
2020-03-19 16:39                 ` [PATCH 2/2 v4] " Sebastian Andrzej Siewior
2020-03-19 16:49                   ` Vlastimil Babka
2020-03-19 16:55                     ` [PATCH 2/2 v5] " Sebastian Andrzej Siewior
2020-03-04  8:18               ` [PATCH 2/2 v3] " Vlastimil Babka
2020-03-04  9:25                 ` Sebastian Andrzej Siewior
2020-03-04  9:11               ` Mel Gorman
2020-03-04  8:12             ` [PATCH 1/2] mm/compaction: Really limit compact_unevictable_allowed to 0…1 Vlastimil Babka

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=20200116102239.m2trw3cvosn7q5a5@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=yzaikin@google.com \
    /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.