From: Yang Shi <yang.shi@linux.alibaba.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
kirill@shutemov.name, hughd@google.com, aaron.lu@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: thp: remove use_zero_page sysfs knob
Date: Fri, 20 Jul 2018 16:49:30 -0700 [thread overview]
Message-ID: <b258c765-ad71-0dd4-d420-75139c55e7c7@linux.alibaba.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1807201401390.231119@chino.kir.corp.google.com>
On 7/20/18 2:05 PM, David Rientjes wrote:
> On Fri, 20 Jul 2018, Yang Shi wrote:
>
>>> We disable the huge zero page through this interface, there were issues
>>> related to the huge zero page shrinker (probably best to never free a
>>> per-node huge zero page after allocated) and CVE-2017-1000405 for huge
>>> dirty COW.
>> Thanks for the information. It looks the CVE has been resolved by commit
>> a8f97366452ed491d13cf1e44241bc0b5740b1f0 ("mm, thp: Do not make page table
>> dirty unconditionally in touch_p[mu]d()"), which is in 4.15 already.
>>
> For users who run kernels earlier than 4.15 they may choose to mitigate
> the CVE by using this tunable. It's not something we permanently need to
> have, but it may likely be too early.
Yes, it might be good to keep it around for a while.
>
>> What was the shrinker related issue? I'm supposed it has been resolved, right?
>>
> The huge zero page can be reclaimed under memory pressure and, if it is,
> it is attempted to be allocted again with gfp flags that attempt memory
> compaction that can become expensive. If we are constantly under memory
> pressure, it gets freed and reallocated millions of times always trying to
> compact memory both directly and by kicking kcompactd in the background.
Even though we don't use huge zero page, we may also run into the
similar issue under memory pressure. Just save the cost of calling huge
zero page shrinker, but actually its cost sound not high.
>
> It likely should also be per node.
next prev parent reply other threads:[~2018-07-20 23:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 18:13 [PATCH] mm: thp: remove use_zero_page sysfs knob Yang Shi
2018-07-20 19:32 ` Andrew Morton
2018-07-20 20:02 ` David Rientjes
2018-07-20 20:37 ` Yang Shi
2018-07-20 21:05 ` David Rientjes
2018-07-20 23:49 ` Yang Shi [this message]
2018-07-22 3:51 ` Matthew Wilcox
2018-07-23 20:28 ` David Rientjes
2018-07-23 21:33 ` David Rientjes
2018-07-23 21:49 ` Yang Shi
2018-07-24 9:08 ` Kirill A. Shutemov
2018-07-24 20:32 ` David Rientjes
2018-07-20 21:06 ` Kirill A. Shutemov
2018-07-20 23:51 ` Yang Shi
2018-07-23 20:31 ` David Rientjes
2018-07-23 21:52 ` Yang Shi
2018-07-23 23:14 ` David Rientjes
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=b258c765-ad71-0dd4-d420-75139c55e7c7@linux.alibaba.com \
--to=yang.shi@linux.alibaba.com \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).