linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Yang Shi <shy828301@gmail.com>
Cc: Linux MM <linux-mm@kvack.org>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Memory compaction and mlockall()
Date: Mon, 12 Aug 2019 16:59:00 +0200	[thread overview]
Message-ID: <77c839c3-7d7d-9b98-5c3d-ad5fd65274b1@suse.cz> (raw)
In-Reply-To: <20190711094324.ninnmarx5r3amz4p@linutronix.de>

On 7/11/19 11:43 AM, Sebastian Andrzej Siewior wrote:
> On 2019-07-10 11:21:19 [-0700], Yang Shi wrote:
>>
>> compaction should not isolate unevictable pages unless you have
>> /proc/sys/vm/compact_unevictable_allowed set.
> 
> Thank you. This is enabled by default. The documentation for this says
> | … compaction is allowed to examine the unevictable lru (mlocked pages) for
> | pages to compact.…
> 
> so it is actually clear once you know where to look.
> If I read this correct, the default behavior was to ignore mlock()ed
> pages for compaction then commit
>   5bbe3547aa3ba ("mm: allow compaction of unevictable pages")
> 
> came along in v4.1-rc1 and changed that behaviour. Is it too late to
> flip it back?

I would say that enabled is a better default wrt benefits for the
majority of systems. This was assuming that mlock() is primarily used to
prevent sensitive data (crypto keys) from hitting swap, not to give
latency guarantees. You could perhaps argue that enabling PREEMPT_RT
might change the default, but it's somewhat subtle.

> Sebastian
> 



  parent reply	other threads:[~2019-08-12 14:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 14:41 Sebastian Andrzej Siewior
2019-07-10 16:20 ` Dave Hansen
2019-07-10 16:45   ` Sebastian Andrzej Siewior
2019-07-10 17:02     ` Dave Hansen
2019-07-10 18:21 ` Yang Shi
2019-07-11  9:43   ` Sebastian Andrzej Siewior
2019-07-11 16:23     ` Yang Shi
2019-08-12 14:59     ` Vlastimil Babka [this message]
2019-08-12 15:54       ` Sebastian Andrzej Siewior
2019-08-13  8:23         ` 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=77c839c3-7d7d-9b98-5c3d-ad5fd65274b1@suse.cz \
    --to=vbabka@suse.cz \
    --cc=bigeasy@linutronix.de \
    --cc=linux-mm@kvack.org \
    --cc=shy828301@gmail.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox