From: Michal Hocko <mhocko@kernel.org>
To: Yang Shi <yang.shi@linux.alibaba.com>
Cc: Laurent Dufour <ldufour@linux.vnet.ibm.com>,
willy@infradead.org, akpm@linux-foundation.org,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
alexander.shishkin@linux.intel.com, jolsa@redhat.com,
namhyung@kernel.org, tglx@linutronix.de, hpa@zytor.com,
linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC v3 PATCH 5/5] x86: check VM_DEAD flag in page fault
Date: Tue, 3 Jul 2018 08:17:13 +0200 [thread overview]
Message-ID: <20180703061713.GB16767@dhcp22.suse.cz> (raw)
In-Reply-To: <a5b4888c-6518-df47-bc0d-d4173984daa9@linux.alibaba.com>
On Mon 02-07-18 11:10:23, Yang Shi wrote:
> On 7/2/18 10:57 AM, Michal Hocko wrote:
[...]
> > Why would you even care about shared mappings?
>
> Just thought about we are dealing with VM_DEAD, which means the vma will be
> tore down soon regardless it is shared or non-shared.
>
> MMF_UNSTABLE doesn't care about !shared case.
Let me clarify some more. MMF_UNSTABLE is there to prevent from
unexpected page faults when the mm is torn down by the oom reaper. And
oom reaper only cares about private mappings because we do not touch
shared ones. Disk based shared mappings should be a non-issue for
VM_DEAD because even if you race and refault a page back then you know
it is the same one you have seen before. Memory backed shared mappings
are a different story because you can get a fresh new page. oom_reaper
doesn't care because it doesn't tear those down. You would have to but
my primary point was that we already have MMF_UNSTABLE so all you need
is to extend it to memory backed shared mappings (shmem and hugetlb).
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-07-03 6:17 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 22:39 [RFC v3 PATCH 0/5] mm: zap pages with read mmap_sem in munmap for large mapping Yang Shi
2018-06-29 22:39 ` Yang Shi
2018-06-29 22:39 ` [RFC v3 PATCH 1/5] uprobes: make vma_has_uprobes non-static Yang Shi
2018-06-29 22:39 ` [RFC v3 PATCH 2/5] mm: introduce VM_DEAD flag Yang Shi
2018-07-02 13:40 ` Michal Hocko
2018-06-29 22:39 ` [RFC v3 PATCH 3/5] mm: refactor do_munmap() to extract the common part Yang Shi
2018-07-02 13:42 ` Michal Hocko
2018-07-02 16:59 ` Yang Shi
2018-07-02 17:58 ` Michal Hocko
2018-07-02 18:02 ` Yang Shi
2018-06-29 22:39 ` [RFC v3 PATCH 4/5] mm: mmap: zap pages with read mmap_sem for large mapping Yang Shi
2018-06-30 1:28 ` Andrew Morton
2018-06-30 2:10 ` Yang Shi
2018-06-30 1:35 ` Andrew Morton
2018-06-30 2:28 ` Yang Shi
2018-06-30 3:15 ` Andrew Morton
2018-06-30 4:26 ` Yang Shi
2018-07-03 0:01 ` Yang Shi
2018-07-03 0:01 ` Yang Shi
2018-07-02 14:05 ` Michal Hocko
2018-07-02 20:48 ` Andrew Morton
2018-07-03 6:09 ` Michal Hocko
2018-07-03 16:53 ` Yang Shi
2018-07-03 18:22 ` Yang Shi
2018-07-04 8:13 ` Michal Hocko
2018-07-02 12:33 ` Kirill A. Shutemov
2018-07-02 12:49 ` Michal Hocko
2018-07-03 8:12 ` Kirill A. Shutemov
2018-07-03 8:27 ` Michal Hocko
2018-07-03 9:19 ` Kirill A. Shutemov
2018-07-03 11:34 ` Michal Hocko
2018-07-03 12:14 ` Kirill A. Shutemov
2018-07-03 17:00 ` Yang Shi
2018-07-02 17:19 ` Yang Shi
2018-07-03 8:07 ` Kirill A. Shutemov
2018-07-02 13:53 ` Michal Hocko
2018-07-02 17:07 ` Yang Shi
2018-06-29 22:39 ` [RFC v3 PATCH 5/5] x86: check VM_DEAD flag in page fault Yang Shi
2018-07-02 8:45 ` Laurent Dufour
2018-07-02 12:15 ` Michal Hocko
2018-07-02 12:26 ` Laurent Dufour
2018-07-02 12:45 ` Michal Hocko
2018-07-02 13:33 ` Laurent Dufour
2018-07-02 13:37 ` Michal Hocko
2018-07-02 17:24 ` Yang Shi
2018-07-02 17:57 ` Michal Hocko
2018-07-02 18:10 ` Yang Shi
2018-07-03 6:17 ` Michal Hocko [this message]
2018-07-03 16:50 ` Yang Shi
2018-07-02 13:39 ` [RFC v3 PATCH 0/5] mm: zap pages with read mmap_sem in munmap for large mapping Michal Hocko
2018-07-02 13:39 ` Michal Hocko
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=20180703061713.GB16767@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=ldufour@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yang.shi@linux.alibaba.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.