linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: John Stultz <john.stultz@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Android Kernel Team <kernel-team@android.com>,
	Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
	Hugh Dickins <hughd@google.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Rik van Riel <riel@redhat.com>,
	Dmitry Adamushko <dmitry.adamushko@gmail.com>,
	Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
	Andrea Righi <andrea@betterlinux.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
	Dhaval Giani <dhaval.giani@gmail.com>, Jan Kara <jack@suse.cz>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Michel Lespinasse <walken@google.com>,
	Rob Clark <robdclark@gmail.com>, Minchan Kim <minchan@kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: [PATCH 03/14] vrange: Clear volatility on new mmaps
Date: Wed,  2 Oct 2013 17:51:32 -0700	[thread overview]
Message-ID: <1380761503-14509-4-git-send-email-john.stultz@linaro.org> (raw)
In-Reply-To: <1380761503-14509-1-git-send-email-john.stultz@linaro.org>

At lsf-mm, the issue was brought up that there is a precedence with
interfaces like mlock, such that new mappings in a pre-existing range
do no inherit the mlock state.

This is mostly because mlock only modifies the existing vmas, and so
any new mmaps create new vmas, which won't be mlocked.

Since volatility is not stored in the vma (for good cause, specifically
as we'd have to have manage file volatility differently from anonymous
and we're likely to manage volatility on small chunks of memory, which
would cause lots of vma splitting and churn), this patch clears volitility
on new mappings, to ensure that we don't inherit volatility if memory in
an existing volatile range is unmapped and then re-mapped with something
else.

Thus, this patch forces any volatility to be cleared on mmap.

XXX: We expect this patch to be not well loved by mm folks, and are open
to alternative methods here. Its more of a place holder to address
the issue from lsf-mm and hopefully will spur some further discussion.

Minchan does have an alternative solution, but I'm not a big fan of it
yet, so this simpler approach is a placeholder for now.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Android Kernel Team <kernel-team@android.com>
Cc: Robert Love <rlove@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Andrea Righi <andrea@betterlinux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Mike Hommey <mh@glandium.org>
Cc: Taras Glek <tglek@mozilla.com>
Cc: Dhaval Giani <dhaval.giani@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Michel Lespinasse <walken@google.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: linux-mm@kvack.org <linux-mm@kvack.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
 include/linux/vrange.h | 2 ++
 mm/mmap.c              | 5 +++++
 mm/vrange.c            | 8 ++++++++
 3 files changed, 15 insertions(+)

diff --git a/include/linux/vrange.h b/include/linux/vrange.h
index 2b96ee1..ef153c8 100644
--- a/include/linux/vrange.h
+++ b/include/linux/vrange.h
@@ -36,6 +36,8 @@ static inline int vrange_type(struct vrange *vrange)
 	return vrange->owner->type;
 }
 
+extern int vrange_clear(struct vrange_root *vroot,
+				unsigned long start, unsigned long end);
 extern void vrange_root_cleanup(struct vrange_root *vroot);
 extern int vrange_fork(struct mm_struct *new,
 					struct mm_struct *old);
diff --git a/mm/mmap.c b/mm/mmap.c
index f9c97d1..ed7056f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -36,6 +36,7 @@
 #include <linux/sched/sysctl.h>
 #include <linux/notifier.h>
 #include <linux/memory.h>
+#include <linux/vrange.h>
 
 #include <asm/uaccess.h>
 #include <asm/cacheflush.h>
@@ -1502,6 +1503,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 	/* Clear old maps */
 	error = -ENOMEM;
 munmap_back:
+
+	/* zap any volatile ranges */
+	vrange_clear(&mm->vroot, addr, addr + len);
+
 	if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent)) {
 		if (do_munmap(mm, addr, len))
 			return -ENOMEM;
diff --git a/mm/vrange.c b/mm/vrange.c
index 4ddcc3e9..f2d1588 100644
--- a/mm/vrange.c
+++ b/mm/vrange.c
@@ -166,6 +166,14 @@ static int vrange_remove(struct vrange_root *vroot,
 	return 0;
 }
 
+int vrange_clear(struct vrange_root *vroot,
+					unsigned long start, unsigned long end)
+{
+	int purged;
+
+	return vrange_remove(vroot, start, end - 1, &purged);
+}
+
 void vrange_root_cleanup(struct vrange_root *vroot)
 {
 	struct vrange *range;
-- 
1.8.1.2

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2013-10-03  0:52 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03  0:51 [PATCH 00/14] Volatile Ranges v9 John Stultz
2013-10-03  0:51 ` [PATCH 01/14] vrange: Add basic data structure and functions John Stultz
2013-10-03  0:51 ` [PATCH 02/14] vrange: Add vrange support to mm_structs John Stultz
2013-10-03  0:51 ` John Stultz [this message]
2013-10-03  0:51 ` [PATCH 04/14] vrange: Add support for volatile ranges on file mappings John Stultz
2013-10-03  0:51 ` [PATCH 05/14] vrange: Add new vrange(2) system call John Stultz
2013-10-07 22:56   ` H. Peter Anvin
2013-10-07 23:14     ` John Stultz
2013-10-07 23:26       ` H. Peter Anvin
2013-10-07 23:41         ` John Stultz
2013-10-07 23:46           ` H. Peter Anvin
2013-10-07 23:54             ` John Stultz
2013-10-07 23:59               ` H. Peter Anvin
2013-10-08  0:13                 ` Minchan Kim
2013-10-08  0:18                   ` John Stultz
2013-10-08  0:34                     ` Minchan Kim
2013-10-08  0:38                       ` Minchan Kim
2013-10-08  1:24                   ` H. Peter Anvin
2013-10-08  2:08                     ` Minchan Kim
2013-10-08  2:51                       ` KOSAKI Motohiro
2013-10-08  3:07                         ` Minchan Kim
2013-10-08  4:35                           ` KOSAKI Motohiro
2013-10-08  7:12                             ` Minchan Kim
2013-10-08  7:17                               ` Minchan Kim
2013-10-08  0:03       ` Minchan Kim
2013-10-08  0:07         ` John Stultz
2013-10-03  0:51 ` [PATCH 06/14] vrange: Add basic functions to purge volatile pages John Stultz
2013-10-03 10:22   ` Krzysztof Kozlowski
2013-10-03  0:51 ` [PATCH 07/14] vrange: Purge volatile pages when memory is tight John Stultz
2013-10-08  3:27   ` Zhan Jianyu
2013-10-08 16:22     ` John Stultz
2013-10-03  0:51 ` [PATCH 08/14] vrange: Send SIGBUS when user try to access purged page John Stultz
2013-10-03  0:51 ` [PATCH 09/14] vrange: Add vrange LRU list for purging John Stultz
2013-10-03  0:51 ` [PATCH 10/14] vrange: Add core shrinking logic for swapless system John Stultz
2013-10-03  0:51 ` [PATCH 11/14] vrange: Purging vrange-anon pages from shrinker John Stultz
2013-10-03  0:51 ` [PATCH 12/14] vrange: Support background purging for vrange-file John Stultz
2013-10-03  0:51 ` [PATCH 13/14] vrange: Allocate vroot dynamically John Stultz
2013-10-03  0:51 ` [PATCH 14/14] vrange: Add vmstat counter about purged page John Stultz
2013-10-03 23:56 ` [PATCH 00/14] Volatile Ranges v9 John Stultz

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=1380761503-14509-4-git-send-email-john.stultz@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrea@betterlinux.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=david@fromorbit.com \
    --cc=dhaval.giani@gmail.com \
    --cc=dmitry.adamushko@gmail.com \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=kernel-team@android.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mh@glandium.org \
    --cc=minchan@kernel.org \
    --cc=neilb@suse.de \
    --cc=riel@redhat.com \
    --cc=rlove@google.com \
    --cc=robdclark@gmail.com \
    --cc=tglek@mozilla.com \
    --cc=walken@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).