From: Andrew Morton <akpm@linux-foundation.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, Thomas Gleixner <tglx@linutronix.de>,
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 v2] mm/compaction: Disable compact_unevictable_allowed on RT
Date: Mon, 2 Mar 2020 13:25:31 -0800 [thread overview]
Message-ID: <20200302132531.59a2c9dffe2515d78abaf909@linux-foundation.org> (raw)
In-Reply-To: <20200302173516.iysuejilava37psk@linutronix.de>
On Mon, 2 Mar 2020 18:35:16 +0100 Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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.
>
> Make compact_unevictable_allowed = 0 default and RO on RT.
hm, that's a bit sad but I guess it's tolerable.
> ...
>
> index 64aeee1009cab..bbfa59d25eec3 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -128,6 +128,7 @@ allowed to examine the unevictable lru (mlocked pages) for pages to compact.
> This should be used on systems where stalls for minor page faults are an
> acceptable trade for large contiguous free memory. Set to 0 to prevent
> compaction from moving pages that are unevictable. Default value is 1.
> +On CONFIG_PREEMPT_RT the default value is 0.
This doesn't mention that the file is unwritable on -rt, and it doesn't
explain *why* -rt has different behaviour.
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1483,7 +1483,11 @@ static struct ctl_table vm_table[] = {
> .procname = "compact_unevictable_allowed",
> .data = &sysctl_compact_unevictable_allowed,
> .maxlen = sizeof(int),
> +#ifdef CONFIG_PREEMPT_RT
> + .mode = 0444,
> +#else
> .mode = 0644,
> +#endif
This is non-backward-compatible and introduces a possibility that
tested-on-non-rt userspace will fail on -rt kernels. It might be
better to accept the writes, but to ignore them. Probably with a
pr_warn_once() to let people know what we did.
But do we really need to take the option away from -rt users? Perhaps
someone wants this feature and can accept the latency hit. How about
switching the default and otherwise leaving the kernel behaviour as-is
and simply emitting a warning letting -rt users know that they might
not want to enable this?
next prev parent reply other threads:[~2020-03-02 21:25 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
2020-03-02 17:35 ` [PATCH v2] " Sebastian Andrzej Siewior
2020-03-02 21:25 ` Andrew Morton [this message]
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=20200302132531.59a2c9dffe2515d78abaf909@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--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.