linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@kernel.org>
Cc: Jann Horn <jannh@google.com>, Linux-MM <linux-mm@kvack.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	Daniel Colascione <dancol@google.com>,
	"Joel Fernandes (Google)" <joel@joelfernandes.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: interaction of MADV_PAGEOUT with CoW anonymous mappings?
Date: Thu, 12 Mar 2020 14:41:07 -0700	[thread overview]
Message-ID: <bd35c17d-8766-cba5-09b3-87970de4c731@intel.com> (raw)
In-Reply-To: <20200312201602.GA68817@google.com>

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

One other fun thing.  I have a "victim" thread sitting in a loop doing:

	sleep(1)
	memcpy(&garbage, buffer, sz);

The "attacker" is doing

	madvise(buffer, sz, MADV_PAGEOUT);

in a loop.  That, oddly enough doesn't cause the victim to page fault.
But, if I do:

	memcpy(&garbage, buffer, sz);
	madvise(buffer, sz, MADV_PAGEOUT);

It *does* cause the memory to get paged out.  The MADV_PAGEOUT code
actually has a !pte_present() check.  It will punt on a PTE if it sees
it.  In other words, if a page is in the swap cache but not mapped by a
pte_present() PTE, MADV_PAGEOUT won't touch it.

Shouldn't MADV_PAGEOUT be able to find and reclaim those pages?  Patch
attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: madv-pageout-find-swap-cache.patch --]
[-- Type: text/x-patch; name="madv-pageout-find-swap-cache.patch", Size: 1692 bytes --]



---

 b/mm/madvise.c |   38 +++++++++++++++++++++++++++++++-------
 1 file changed, 31 insertions(+), 7 deletions(-)

diff -puN mm/madvise.c~madv-pageout-find-swap-cache mm/madvise.c
--- a/mm/madvise.c~madv-pageout-find-swap-cache	2020-03-12 14:24:45.178775035 -0700
+++ b/mm/madvise.c	2020-03-12 14:35:49.706773378 -0700
@@ -248,6 +248,36 @@ static void force_shm_swapin_readahead(s
 #endif		/* CONFIG_SWAP */
 
 /*
+ * Given a PTE, find the corresponding 'struct page'.  Also handles
+ * non-present swap PTEs.
+ */
+struct page *pte_to_reclaim_page(struct vm_area_struct *vma,
+				 unsigned long addr, pte_t ptent)
+{
+	swp_entry_t entry;
+
+	/* Totally empty PTE: */
+	if (pte_none(ptent))
+		return NULL;
+
+	/* A normal, present page is mapped: */
+	if (pte_present(ptent))
+		return vm_normal_page(vma, addr, ptent);
+
+	entry = pte_to_swp_entry(vmf->orig_pte);
+	/* Is it one of the "swap PTEs" that's not really swap? */
+	if (non_swap_entry(entry))
+		return false;
+
+	/*
+	 * The PTE was a true swap entry.  The page may be in the
+	 * swap cache.  If so, find it and return it so it may be
+	 * reclaimed.
+	 */
+	return lookup_swap_cache(entry, vma, addr);
+}
+
+/*
  * Schedule all required I/O operations.  Do not wait for completion.
  */
 static long madvise_willneed(struct vm_area_struct *vma,
@@ -389,13 +419,7 @@ regular_page:
 	for (; addr < end; pte++, addr += PAGE_SIZE) {
 		ptent = *pte;
 
-		if (pte_none(ptent))
-			continue;
-
-		if (!pte_present(ptent))
-			continue;
-
-		page = vm_normal_page(vma, addr, ptent);
+		page = pte_to_reclaim_page(vma, addr, ptent);
 		if (!page)
 			continue;
 
_

  parent reply	other threads:[~2020-03-12 21:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 18:08 interaction of MADV_PAGEOUT with CoW anonymous mappings? Jann Horn
2020-03-10 18:48 ` Michal Hocko
2020-03-10 19:11   ` Jann Horn
2020-03-10 21:09     ` Michal Hocko
2020-03-10 22:48       ` Dave Hansen
2020-03-11  8:45         ` Michal Hocko
2020-03-11 22:02           ` Minchan Kim
2020-03-11 23:53           ` Shakeel Butt
2020-03-12  0:18             ` Minchan Kim
2020-03-12  2:03               ` Daniel Colascione
2020-03-12 15:15                 ` Shakeel Butt
2020-03-10 20:19   ` Daniel Colascione
2020-03-10 21:40     ` Jann Horn
2020-03-10 21:52       ` Daniel Colascione
2020-03-10 22:14 ` Minchan Kim
2020-03-12  8:22 ` Michal Hocko
2020-03-12 15:40   ` Vlastimil Babka
2020-03-12 20:16   ` Minchan Kim
2020-03-12 20:26     ` Dave Hansen
2020-03-12 20:41     ` Michal Hocko
2020-03-13  2:08       ` Minchan Kim
2020-03-13  8:05         ` Michal Hocko
2020-03-13 20:59           ` Minchan Kim
2020-03-16  9:20             ` Michal Hocko
2020-03-17  1:43               ` Minchan Kim
2020-03-17  7:12                 ` Michal Hocko
2020-03-17 15:00                   ` Minchan Kim
2020-03-17 15:58                     ` Michal Hocko
2020-03-17 17:20                       ` Minchan Kim
2020-03-12 21:41     ` Dave Hansen [this message]
2020-03-13  2:00       ` Minchan Kim
2020-03-13 16:59         ` Dave Hansen
2020-03-13 21:13           ` Minchan Kim
2020-03-12 23:29     ` Jann Horn

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=bd35c17d-8766-cba5-09b3-87970de4c731@intel.com \
    --to=dave.hansen@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dancol@google.com \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    /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).