Volatile Ranges (v11)

This patch introduces the vrange() syscall, which allows for specifying ranges of memory as volatile, and able to be discarded by the system.

This initial patch simply adds the syscall, and the vma handling, splitting and merging the vmas as needed, and marking them with VM_VOLATILE.

No purging or discarding of volatile ranges is done at this point.

Example man page:

NAME
vrange - Mark or unmark range of memory as volatile

SYNOPSIS

	int vrange(unsigned_long start, size_t length, int mode,
			 int *purged);

DESCRIPTION
Applications can use vrange(2) to advise the kernel how it should handle paging I/O in this VM area. The idea is to help the kernel discard pages of vrange instead of reclaiming when memory pressure happens. It means kernel doesn't discard any pages of vrange if there is no memory pressure.

mode:
VRANGE_VOLATILE
hint to kernel so VM can discard in vrange pages when memory pressure happens.
VRANGE_NONVOLATILE
hint to kernel so VM doesn't discard vrange pages any more.

If user try to access purged memory without VRANGE_NONVOLATILE call,

he can encounter SIGBUS if the page was discarded by kernel.

purged: Pointer to an integer which will return 1 if mode == VRANGE_NONVOLATILE and any page in the affected range was purged. If purged returns zero during a mode == VRANGE_NONVOLATILE call, it means all of the pages in the range are intact.

RETURN VALUE
On success vrange returns the number of bytes marked or unmarked. Similar to write(), it may return fewer bytes then specified if it ran into a problem.

If an error is returned, no changes were made.

ERRORS
EINVAL This error can occur for the following reasons:
* The value length is negative or not page size units.
* addr is not page-aligned
* mode not a valid value.

ENOMEM Not enough memory

EFAULT purged pointer is invalid

This a simplified implementation which reuses some of the logic from Minchan's earlier efforts. So credit to Minchan for his work.

Cc Andrew Morton <[email protected]>

Cc Android Kernel Team <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Robert Love <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Rik van Riel <[email protected]>

Cc Dmitry Adamushko <[email protected]>

Cc Neil Brown <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Mike Hommey <[email protected]>

Cc Taras Glek <[email protected]>

Cc Dhaval Giani <[email protected]>

Cc Jan Kara <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc Michel Lespinasse <[email protected]>

Cc Minchan Kim <[email protected]>

Cc [email protected] <[email protected]>

Signed-off-by John Stultz <[email protected]>

---
 arch/x86/syscalls/syscall_64.tbl |   1 +
 include/linux/mm.h               |   1 +
 include/linux/vrange.h           |   7 ++
 mm/Makefile                      |   2 +-
 mm/vrange.c                      | 150 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 160 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/vrange.h
 create mode 100644 mm/vrange.c

arch/x86/syscalls/syscall_64.tbl +1 -0

index a12bddc..7ae3940 100644
@@ -322,6 +322,7 @@
 313	common	finit_module		sys_finit_module
 314	common	sched_setattr		sys_sched_setattr
 315	common	sched_getattr		sys_sched_getattr
+316	common	vrange			sys_vrange
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact

include/linux/mm.h +1 -0

index c1b7414..a1f11da 100644
@@ -117,6 +117,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_IO           0x00004000	/* Memory mapped I/O or similar */
 
 					/* Used by sys_madvise() */
+#define VM_VOLATILE	0x00001000	/* VMA is volatile */
 #define VM_SEQ_READ	0x00008000	/* App will access data sequentially */
 #define VM_RAND_READ	0x00010000	/* App will not benefit from clustered reads */
 

include/linux/vrange.h new file +7 -0

new file mode 100644
index 0000000..652396b
@@ -0,0 +1,7 @@
+#ifndef _LINUX_VRANGE_H
+#define _LINUX_VRANGE_H
+
+#define VRANGE_NONVOLATILE 0
+#define VRANGE_VOLATILE 1
+
+#endif /* _LINUX_VRANGE_H */

mm/Makefile +1 -1

index 310c90a..20229e2 100644
@@ -16,7 +16,7 @@ obj-y			:= filemap.o mempool.o oom_kill.o fadvise.o \
 			   readahead.o swap.o truncate.o vmscan.o shmem.o \
 			   util.o mmzone.o vmstat.o backing-dev.o \
 			   mm_init.o mmu_context.o percpu.o slab_common.o \
-			   compaction.o balloon_compaction.o \
+			   compaction.o balloon_compaction.o vrange.o \
 			   interval_tree.o list_lru.o $(mmu-y)
 
 obj-y += init-mm.o

mm/vrange.c new file +79 -0

new file mode 100644
index 0000000..acb4356
@@ -0,0 +1,150 @@
+#include <linux/syscalls.h>
+#include <linux/vrange.h>
+#include <linux/mm_inline.h>
+#include <linux/pagemap.h>
+#include <linux/rmap.h>
+#include <linux/hugetlb.h>
+#include <linux/mmu_notifier.h>
+#include <linux/mm_inline.h>
+#include "internal.h"
+
+static ssize_t do_vrange(struct mm_struct *mm, unsigned long start,
+				unsigned long end, int mode, int *purged)
+{
+	struct vm_area_struct *vma, *prev;
+	unsigned long orig_start = start;
+	ssize_t count = 0, ret = 0;
+	int lpurged = 0;
+
+	down_read(&mm->mmap_sem);
+
+	vma = find_vma_prev(mm, start, &prev);
+	if (vma && start > vma->vm_start)
+		prev = vma;
+
+	for (;;) {
+		unsigned long new_flags;
+		pgoff_t pgoff;
+		unsigned long tmp;
+
+		if (!vma)
+			goto out;
+
+		if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
+					VM_HUGETLB))
+			goto out;
+
+		/* We don't support volatility on files for now */
+		if (vma->vm_file) {
+			ret = -EINVAL;
+			goto out;
+		}
+
+		new_flags = vma->vm_flags;
+
+		if (start < vma->vm_start) {
+			start = vma->vm_start;
+			if (start >= end)
+				goto out;
+		}
+		tmp = vma->vm_end;
+		if (end < tmp)
+			tmp = end;
+
+		switch (mode) {
+		case VRANGE_VOLATILE:
+			new_flags |= VM_VOLATILE;
+			break;
+		case VRANGE_NONVOLATILE:
+			new_flags &= ~VM_VOLATILE;
+		}
+
+		pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
+		prev = vma_merge(mm, prev, start, tmp, new_flags,
+					vma->anon_vma, vma->vm_file, pgoff,
+					vma_policy(vma));
+		if (prev)
+			goto success;
+
+		if (start != vma->vm_start) {
+			ret = split_vma(mm, vma, start, 1);
+			if (ret)
+				goto out;
+		}
+
+		if (tmp != vma->vm_end) {
+			ret = split_vma(mm, vma, tmp, 0);
+			if (ret)
+				goto out;
+		}

mm/vrange.c new file +44 -0

+	}
+out:
+	up_read(&mm->mmap_sem);
+
+	/* report bytes successfully marked, even if we're exiting on error */
+	if (count)
+		return count;
+
+	return ret;
+}
+
+SYSCALL_DEFINE4(vrange, unsigned long, start,
+		size_t, len, int, mode, int __user *, purged)
+{
+	unsigned long end;
+	struct mm_struct *mm = current->mm;
+	ssize_t ret = -EINVAL;
+	int p = 0;
+
+	if (start & ~PAGE_MASK)
+		goto out;
+
+	len &= PAGE_MASK;
+	if (!len)
+		goto out;
+
+	end = start + len;
+	if (end < start)
+		goto out;
+
+	if (start >= TASK_SIZE)
+		goto out;
+
+	if (purged) {
+		/* Test pointer is valid before making any changes */
+		if (put_user(p, purged))
+			return -EFAULT;
+	}
+
+	ret = do_vrange(mm, start, end, mode, &p);
+
+	if (purged) {
+		if (put_user(p, purged)) {
+			/*

Quoted 17 lines · John Stultz

mm/vrange.c new file +17 -0

+	for (;;) {
+		unsigned long new_flags;
+		pgoff_t pgoff;
+		unsigned long tmp;
+
+		if (!vma)
+			goto out;
+
+		if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
+					VM_HUGETLB))
+			goto out;
+
+		/* We don't support volatility on files for now */
+		if (vma->vm_file) {
+			ret = -EINVAL;
+			goto out;
+		}

mm/vrange.c line 49

Quoted 8 lines

mm/vrange.c new file +8 -0

+
+		new_flags = vma->vm_flags;
+
+		if (start < vma->vm_start) {
+			start = vma->vm_start;
+			if (start >= end)
+				goto out;
+		}

Quoted 30 lines

mm/vrange.c new file +30 -0

+		tmp = vma->vm_end;
+		if (end < tmp)
+			tmp = end;
+
+		switch (mode) {
+		case VRANGE_VOLATILE:
+			new_flags |= VM_VOLATILE;
+			break;
+		case VRANGE_NONVOLATILE:
+			new_flags &= ~VM_VOLATILE;
+		}
+
+		pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
+		prev = vma_merge(mm, prev, start, tmp, new_flags,
+					vma->anon_vma, vma->vm_file, pgoff,
+					vma_policy(vma));
+		if (prev)
+			goto success;
+
+		if (start != vma->vm_start) {
+			ret = split_vma(mm, vma, start, 1);
+			if (ret)
+				goto out;
+		}
+
+		if (tmp != vma->vm_end) {
+			ret = split_vma(mm, vma, tmp, 0);
+			if (ret)
+				goto out;
+		}

mm/vrange.c line 89

Quoted 10 lines

mm/vrange.c new file +10 -0

+
+		prev = vma;
+success:
+		vma->vm_flags = new_flags;
+		*purged = lpurged;
+
+		/* update count to distance covered so far*/
+		count = tmp - orig_start;
+
+		if (prev && start < prev->vm_end)

In which case 'prev' can be NULL? And when start >= prev->vm_end? In all
the cases I can come up with this condition seems to be true...

mm/vrange.c line 93

Quoted 4 lines

mm/vrange.c new file +4 -0

+			start = prev->vm_end;
+		if (start >= end)
+			goto out;
+		if (prev)

Ditto regarding 'prev'...

mm/vrange.c line 96

Quoted 3 lines

mm/vrange.c new file +3 -0

+			vma = prev->vm_next;
+		else	/* madvise_remove dropped mmap_sem */
+			vma = find_vma(mm, start);

The comment regarding madvise_remove() looks bogus...

Quoted 44 lines

mm/vrange.c new file +44 -0

+	}
+out:
+	up_read(&mm->mmap_sem);
+
+	/* report bytes successfully marked, even if we're exiting on error */
+	if (count)
+		return count;
+
+	return ret;
+}
+
+SYSCALL_DEFINE4(vrange, unsigned long, start,
+		size_t, len, int, mode, int __user *, purged)
+{
+	unsigned long end;
+	struct mm_struct *mm = current->mm;
+	ssize_t ret = -EINVAL;
+	int p = 0;
+
+	if (start & ~PAGE_MASK)
+		goto out;
+
+	len &= PAGE_MASK;
+	if (!len)
+		goto out;
+
+	end = start + len;
+	if (end < start)
+		goto out;
+
+	if (start >= TASK_SIZE)
+		goto out;
+
+	if (purged) {
+		/* Test pointer is valid before making any changes */
+		if (put_user(p, purged))
+			return -EFAULT;
+	}
+
+	ret = do_vrange(mm, start, end, mode, &p);
+
+	if (purged) {
+		if (put_user(p, purged)) {
+			/*

mm/vrange.c line 150

Quoted 10 lines

mm/vrange.c new file +10 -0

+			 * This would be bad, since we've modified volatilty
+			 * and the change in purged state would be lost.
+			 */
+			WARN_ONCE(1, "vrange: purge state possibly lost\n");
+		}
+	}
+
+out:
+	return ret;
+}

Honza

Signature · 2 lines

Jan Kara <[email protected]>
SUSE Labs, CR

Quoted 22 lines · Jan Kara

Quoted 21 lines · John Stultz

mm/vrange.c new file +21 -0

+	for (;;) {
+		unsigned long new_flags;
+		pgoff_t pgoff;
+		unsigned long tmp;
+
+		if (!vma)
+			goto out;
+
+		if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
+					VM_HUGETLB))
+			goto out;
+
+		/* We don't support volatility on files for now */
+		if (vma->vm_file) {
+			ret = -EINVAL;
+			goto out;
+		}
+
+		new_flags = vma->vm_flags;
+
+		if (start < vma->vm_start) {

Quoted 4 lines

mm/vrange.c line 49

Quoted 4 lines

mm/vrange.c new file +4 -0

+			start = vma->vm_start;
+			if (start >= end)
+				goto out;
+		}

One more question: This seems to silently skip any holes between VMAs. Is
that really intended? I'd expect that marking unmapped range as volatile / non-volatile should return error... In any case what happens should be defined in the description.

Quoted 18 lines · John Stultz

This patch introduces the vrange() syscall, which allows for specifying ranges of memory as volatile, and able to be discarded by the system.

This initial patch simply adds the syscall, and the vma handling, splitting and merging the vmas as needed, and marking them with VM_VOLATILE.

No purging or discarding of volatile ranges is done at this point.

Example man page:

NAME
vrange - Mark or unmark range of memory as volatile

SYNOPSIS

	int vrange(unsigned_long start, size_t length, int mode,
			 int *purged);

Quoted 6 lines

DESCRIPTION
Applications can use vrange(2) to advise the kernel how it should handle paging I/O in this VM area. The idea is to help the kernel discard pages of vrange instead of reclaiming when memory pressure happens. It means kernel doesn't discard any pages of vrange if there is no memory pressure.

I'd say that the advantage is kernel doesn't have to swap volatile pages,
it can just directly discard them on memory pressure. You should also mention somewhere vrange() is currently supported only for anonymous pages. So maybe we can have the description like:
Applications can use vrange(2) to advise kernel that pages of anonymous mapping in the given VM area can be reclaimed without swapping (or can no longer be reclaimed without swapping). The idea is that application can help kernel with page reclaim under memory pressure by specifying data it can easily regenerate and thus kernel can discard the data if needed.

Quoted 10 lines

mode:
VRANGE_VOLATILE
hint to kernel so VM can discard in vrange pages when memory pressure happens.
VRANGE_NONVOLATILE
hint to kernel so VM doesn't discard vrange pages any more.

If user try to access purged memory without VRANGE_NONVOLATILE call,

                ^^^ tries

Quoted 8 lines

he can encounter SIGBUS if the page was discarded by kernel.

purged: Pointer to an integer which will return 1 if mode == VRANGE_NONVOLATILE and any page in the affected range was purged. If purged returns zero during a mode == VRANGE_NONVOLATILE call, it means all of the pages in the range are intact.

Quoted 4 lines

RETURN VALUE
On success vrange returns the number of bytes marked or unmarked. Similar to write(), it may return fewer bytes then specified if it ran into a problem.

I believe you may need to better explain what is 'purged' argument good
for. Because in my naive understanding *purged == 1 iff return value != length. I recall your discussion with Johannes about error conditions and the need to return error but also the state of the range, is that right? But that should be really explained somewhere so that poor application programmer is aware of those corner cases as well.

Quoted 85 lines

mm/vrange.c new file +79 -0

new file mode 100644
index 0000000..acb4356
@@ -0,0 +1,150 @@
+#include <linux/syscalls.h>
+#include <linux/vrange.h>
+#include <linux/mm_inline.h>
+#include <linux/pagemap.h>
+#include <linux/rmap.h>
+#include <linux/hugetlb.h>
+#include <linux/mmu_notifier.h>
+#include <linux/mm_inline.h>
+#include "internal.h"
+
+static ssize_t do_vrange(struct mm_struct *mm, unsigned long start,
+				unsigned long end, int mode, int *purged)
+{
+	struct vm_area_struct *vma, *prev;
+	unsigned long orig_start = start;
+	ssize_t count = 0, ret = 0;
+	int lpurged = 0;
+
+	down_read(&mm->mmap_sem);
+
+	vma = find_vma_prev(mm, start, &prev);
+	if (vma && start > vma->vm_start)
+		prev = vma;
+
+	for (;;) {
+		unsigned long new_flags;
+		pgoff_t pgoff;
+		unsigned long tmp;
+
+		if (!vma)
+			goto out;
+
+		if (vma->vm_flags & (VM_SPECIAL|VM_LOCKED|VM_MIXEDMAP|
+					VM_HUGETLB))
+			goto out;
+
+		/* We don't support volatility on files for now */
+		if (vma->vm_file) {
+			ret = -EINVAL;
+			goto out;
+		}
+
+		new_flags = vma->vm_flags;
+
+		if (start < vma->vm_start) {
+			start = vma->vm_start;
+			if (start >= end)
+				goto out;
+		}
+		tmp = vma->vm_end;
+		if (end < tmp)
+			tmp = end;
+
+		switch (mode) {
+		case VRANGE_VOLATILE:
+			new_flags |= VM_VOLATILE;
+			break;
+		case VRANGE_NONVOLATILE:
+			new_flags &= ~VM_VOLATILE;
+		}
+
+		pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);
+		prev = vma_merge(mm, prev, start, tmp, new_flags,
+					vma->anon_vma, vma->vm_file, pgoff,
+					vma_policy(vma));
+		if (prev)
+			goto success;
+
+		if (start != vma->vm_start) {
+			ret = split_vma(mm, vma, start, 1);
+			if (ret)
+				goto out;
+		}
+
+		if (tmp != vma->vm_end) {
+			ret = split_vma(mm, vma, tmp, 0);
+			if (ret)
+				goto out;
+		}

mm/vrange.c line 89

Quoted 10 lines

mm/vrange.c new file +10 -0

+
+		prev = vma;
+success:
+		vma->vm_flags = new_flags;
+		*purged = lpurged;
+
+		/* update count to distance covered so far*/
+		count = tmp - orig_start;
+
+		if (prev && start < prev->vm_end)

In which case 'prev' can be NULL? And when start >= prev->vm_end? In all
the cases I can come up with this condition seems to be true...

mm/vrange.c line 93

Quoted 4 lines

mm/vrange.c new file +4 -0

+			start = prev->vm_end;
+		if (start >= end)
+			goto out;
+		if (prev)

Ditto regarding 'prev'...

mm/vrange.c line 96

Quoted 3 lines

mm/vrange.c new file +3 -0

+			vma = prev->vm_next;
+		else	/* madvise_remove dropped mmap_sem */
+			vma = find_vma(mm, start);

The comment regarding madvise_remove() looks bogus...

Users of volatile ranges will need to know if memory was discarded. This patch adds the purged state tracking required to inform userland when it marks memory as non-volatile that some memory in that range was purged and needs to be regenerated.

This simplified implementation which uses some of the logic from Minchan's earlier efforts, so credit to Minchan for his work.

Cc Andrew Morton <[email protected]>

Cc Android Kernel Team <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Robert Love <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Rik van Riel <[email protected]>

Cc Dmitry Adamushko <[email protected]>

Cc Neil Brown <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Mike Hommey <[email protected]>

Cc Taras Glek <[email protected]>

Cc Dhaval Giani <[email protected]>

Cc Jan Kara <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc Michel Lespinasse <[email protected]>

Cc Minchan Kim <[email protected]>

Cc [email protected] <[email protected]>

Signed-off-by John Stultz <[email protected]>

---
 include/linux/swap.h   | 15 +++++++++++--
 include/linux/vrange.h | 13 ++++++++++++
 mm/vrange.c            | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+), 2 deletions(-)

include/linux/swap.h +13 -2

index 46ba0c6..18c12f9 100644
@@ -70,8 +70,19 @@ static inline int current_is_kswapd(void)
 #define SWP_HWPOISON_NUM 0
 #endif
 
-#define MAX_SWAPFILES \
-	((1 << MAX_SWAPFILES_SHIFT) - SWP_MIGRATION_NUM - SWP_HWPOISON_NUM)
+
+/*
+ * Purged volatile range pages
+ */
+#define SWP_VRANGE_PURGED_NUM 1
+#define SWP_VRANGE_PURGED (MAX_SWAPFILES + SWP_HWPOISON_NUM + SWP_MIGRATION_NUM)
+
+
+#define MAX_SWAPFILES ((1 << MAX_SWAPFILES_SHIFT)	\
+				- SWP_MIGRATION_NUM	\
+				- SWP_HWPOISON_NUM	\
+				- SWP_VRANGE_PURGED_NUM	\
+			)
 
 /*
  * Magic header for a swap area. The first part of the union is

include/linux/vrange.h +13 -0

index 652396b..c4a1616 100644
@@ -1,7 +1,20 @@
 #ifndef _LINUX_VRANGE_H
 #define _LINUX_VRANGE_H
 
+#include <linux/swap.h>
+#include <linux/swapops.h>
+
 #define VRANGE_NONVOLATILE 0
 #define VRANGE_VOLATILE 1
 
+static inline swp_entry_t swp_entry_mk_vrange_purged(void)
+{
+	return swp_entry(SWP_VRANGE_PURGED, 0);
+}
+
+static inline int entry_is_vrange_purged(swp_entry_t entry)
+{
+	return swp_type(entry) == SWP_VRANGE_PURGED;
+}
+
 #endif /* _LINUX_VRANGE_H */

mm/vrange.c +0 -0

index acb4356..844571b 100644

mm/vrange.c +22 -0

+};
+
+static int vrange_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
+				struct mm_walk *walk)
+{
+	struct vrange_walker *vw = walk->private;
+	pte_t *pte;
+	spinlock_t *ptl;
+
+	if (pmd_trans_huge(*pmd))
+		return 0;
+	if (pmd_trans_unstable(pmd))
+		return 0;
+
+	pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
+	for (; addr != end; pte++, addr += PAGE_SIZE) {
+		if (!pte_present(*pte)) {
+			swp_entry_t vrange_entry = pte_to_swp_entry(*pte);
+
+			if (unlikely(entry_is_vrange_purged(vrange_entry))) {
+				vw->pages_purged = 1;
+				break;

mm/vrange.c +19 -0

+					 struct vm_area_struct *vma,
+					 unsigned long start,
+					 unsigned long end)
+{
+	struct vrange_walker vw;
+	struct mm_walk vrange_walk = {
+		.pmd_entry = vrange_pte_range,
+		.mm = vma->vm_mm,
+		.private = &vw,
+	};
+	vw.pages_purged = 0;
+	vw.vma = vma;
+
+	walk_page_range(start, end, &vrange_walk);
+
+	return vw.pages_purged;
+
+}
+
 static ssize_t do_vrange(struct mm_struct *mm, unsigned long start,
 				unsigned long end, int mode, int *purged)
 {

mm/vrange.c +0 -0

 		}
 
 		pgoff = vma->vm_pgoff + ((start - vma->vm_start) >> PAGE_SHIFT);

Signature · 1 line

1.8.3.2

Quoted 7 lines · John Stultz

Users of volatile ranges will need to know if memory was discarded. This patch adds the purged state tracking required to inform userland when it marks memory as non-volatile that some memory in that range was purged and needs to be regenerated.

This simplified implementation which uses some of the logic from Minchan's earlier efforts, so credit to Minchan for his work.

Some minor comments below...

Quoted 85 lines

Cc Andrew Morton <[email protected]>

Cc Android Kernel Team <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Robert Love <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Rik van Riel <[email protected]>

Cc Dmitry Adamushko <[email protected]>

Cc Neil Brown <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Mike Hommey <[email protected]>

Cc Taras Glek <[email protected]>

Cc Dhaval Giani <[email protected]>

Cc Jan Kara <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc Michel Lespinasse <[email protected]>

Cc Minchan Kim <[email protected]>

Cc [email protected] <[email protected]>

Signed-off-by John Stultz <[email protected]>

---
 include/linux/swap.h   | 15 +++++++++++--
 include/linux/vrange.h | 13 ++++++++++++
 mm/vrange.c            | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+), 2 deletions(-)

include/linux/swap.h +13 -2

index 46ba0c6..18c12f9 100644
@@ -70,8 +70,19 @@ static inline int current_is_kswapd(void)
 #define SWP_HWPOISON_NUM 0
 #endif
 
-#define MAX_SWAPFILES \
-	((1 << MAX_SWAPFILES_SHIFT) - SWP_MIGRATION_NUM - SWP_HWPOISON_NUM)
+
+/*
+ * Purged volatile range pages
+ */
+#define SWP_VRANGE_PURGED_NUM 1
+#define SWP_VRANGE_PURGED (MAX_SWAPFILES + SWP_HWPOISON_NUM + SWP_MIGRATION_NUM)
+
+
+#define MAX_SWAPFILES ((1 << MAX_SWAPFILES_SHIFT)	\
+				- SWP_MIGRATION_NUM	\
+				- SWP_HWPOISON_NUM	\
+				- SWP_VRANGE_PURGED_NUM	\
+			)
 
 /*
  * Magic header for a swap area. The first part of the union is

include/linux/vrange.h +13 -0

index 652396b..c4a1616 100644
@@ -1,7 +1,20 @@
 #ifndef _LINUX_VRANGE_H
 #define _LINUX_VRANGE_H
 
+#include <linux/swap.h>
+#include <linux/swapops.h>
+
 #define VRANGE_NONVOLATILE 0
 #define VRANGE_VOLATILE 1
 
+static inline swp_entry_t swp_entry_mk_vrange_purged(void)
+{
+	return swp_entry(SWP_VRANGE_PURGED, 0);
+}
+
+static inline int entry_is_vrange_purged(swp_entry_t entry)
+{
+	return swp_type(entry) == SWP_VRANGE_PURGED;
+}
+
 #endif /* _LINUX_VRANGE_H */

mm/vrange.c +0 -0

index acb4356..844571b 100644
@@ -8,6 +8,60 @@
 #include <linux/mm_inline.h>
 #include "internal.h"
 

mm/vrange.c line 13

Quoted 3 lines

mm/vrange.c +3 -0

+struct vrange_walker {
+	struct vm_area_struct *vma;
+	int pages_purged;

Maybe call this 'was_page_purged'? To better suggest the value is bool
and not a number of pages... Or make that 'bool' instead of 'int'?

Quoted 27 lines

mm/vrange.c +26 -0

+};
+
+static int vrange_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
+				struct mm_walk *walk)
+{
+	struct vrange_walker *vw = walk->private;
+	pte_t *pte;
+	spinlock_t *ptl;
+
+	if (pmd_trans_huge(*pmd))
+		return 0;
+	if (pmd_trans_unstable(pmd))
+		return 0;
+
+	pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
+	for (; addr != end; pte++, addr += PAGE_SIZE) {
+		if (!pte_present(*pte)) {
+			swp_entry_t vrange_entry = pte_to_swp_entry(*pte);
+
+			if (unlikely(entry_is_vrange_purged(vrange_entry))) {
+				vw->pages_purged = 1;
+				break;
+			}
+		}
+	}
+	pte_unmap_unlock(pte - 1, ptl);

mm/vrange.c line 45

Quoted 6 lines

mm/vrange.c +6 -0

+	cond_resched();
+
+	return 0;
+}
+
+static unsigned long vrange_check_purged(struct mm_struct *mm,

What's the point of this function returning ulong when everything else
expects 'int'?

Quoted 24 lines

mm/vrange.c +19 -0

+					 struct vm_area_struct *vma,
+					 unsigned long start,
+					 unsigned long end)
+{
+	struct vrange_walker vw;
+	struct mm_walk vrange_walk = {
+		.pmd_entry = vrange_pte_range,
+		.mm = vma->vm_mm,
+		.private = &vw,
+	};
+	vw.pages_purged = 0;
+	vw.vma = vma;
+
+	walk_page_range(start, end, &vrange_walk);
+
+	return vw.pages_purged;
+
+}
+
 static ssize_t do_vrange(struct mm_struct *mm, unsigned long start,
 				unsigned long end, int mode, int *purged)
 {

@@ -57,6 +111,9 @@ static ssize_t do_vrange(struct mm_struct *mm, unsigned long start,
 			break;

mm/vrange.c static ssize_t do_vrange(struct mm_struct *mm, unsigned long start, · line 116

Quoted 5 lines

mm/vrange.c +3 -0

 		case VRANGE_NONVOLATILE:
 			new_flags &= ~VM_VOLATILE;
+			lpurged |= vrange_check_purged(mm, vma,
+							vma->vm_start,
+							vma->vm_end);

Hum, why don't you actually just call vrange_check_purge() once for the
whole syscall range? walk_page_range() seems to handle multiple vmas just fine...

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

On Fri 14-03-14 11:33:30, John Stultz wrote:
[...]

Quoted 8 lines

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

Maybe I have missed something (I've only glanced through the patches) but it seems that marking a range volatile doesn't alter neither reference bits nor position in the LRU. I thought that a volatile page would be moved to the end of inactive LRU with the reference bit dropped. Or is this expectation wrong and volatility is not supposed to touch page aging?

On Fri 14-03-14 11:33:30, John Stultz wrote:
[...]

Quoted 8 lines

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

Maybe I have missed something (I've only glanced through the patches) but it seems that marking a range volatile doesn't alter neither reference bits nor position in the LRU. I thought that a volatile page would be moved to the end of inactive LRU with the reference bit dropped. Or is this expectation wrong and volatility is not supposed to touch page aging?

Quoted 10 lines · Michal Hocko

On Fri 14-03-14 11:33:30, John Stultz wrote:
[...]

Quoted 8 lines

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

Quoted 6 lines

Maybe I have missed something (I've only glanced through the patches) but it seems that marking a range volatile doesn't alter neither reference bits nor position in the LRU. I thought that a volatile page would be moved to the end of inactive LRU with the reference bit dropped. Or is this expectation wrong and volatility is not supposed to touch page aging?

I'm not really convinced it should alter the aging. Things could potentially go in and out of volatile state frequently, and requiring aging means we've got to go after them page-by-page or pte-by-pte at best. That doesn't seem like something we want to do in a path we want to be fast.

Why not just let normal page aging deal with them? It seems to me like like trying to infer intended lru position from volatility is the wrong thing. It's quite possible we'd have two pages in the same range that we want in completely different parts of the LRU. Maybe the structure has a hot page and a cold one, and we would ideally want the cold one swapped out and not the hot one.

Quoted 11 lines · Michal Hocko

On Fri 14-03-14 11:33:30, John Stultz wrote:
[...]

Quoted 8 lines

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

Quoted 6 lines

Maybe I have missed something (I've only glanced through the patches) but it seems that marking a range volatile doesn't alter neither reference bits nor position in the LRU. I thought that a volatile page would be moved to the end of inactive LRU with the reference bit dropped. Or is this expectation wrong and volatility is not supposed to touch page aging?

I'm not really convinced it should alter the aging. Things could potentially go in and out of volatile state frequently, and requiring aging means we've got to go after them page-by-page or pte-by-pte at best. That doesn't seem like something we want to do in a path we want to be fast.

Why not just let normal page aging deal with them? It seems to me like like trying to infer intended lru position from volatility is the wrong thing. It's quite possible we'd have two pages in the same range that we want in completely different parts of the LRU. Maybe the structure has a hot page and a cold one, and we would ideally want the cold one swapped out and not the hot one.

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

I recently got a chance to try to implement Johannes' suggested approach so I wanted to send it out for comments. It looks like Minchan has also done the same, but from a different direction, focusing on the MADV_FREE use cases. I think both approaches are valid, so I wouldn't consider

these patches to be in conflict. Its just that earlier iterations of the volatile range patches had tried to handle numerous different use cases, and the resulting complexity was apparently making it difficult to review and get interest in the patch set. So basically we're splitting the use cases up and trying to find simpler solutions for each.

I'd greatly appreciate any feedback or thoughts!

thanks
-john

Volatile ranges provides a method for userland to inform the kernel that a range of memory is safe to discard (ie: can be regenerated) but userspace may want to try access it in the future. It can be thought of as similar to MADV_DONTNEED, but that the actual freeing of the memory is delayed and only done under memory pressure, and the user can try to cancel the action and be able to quickly access any unpurged pages. The idea originated from Android's ashmem, but I've since learned that other OSes provide similar functionality.

This functionality allows for a number of interesting uses:
* Userland caches that have kernel triggered eviction under memory pressure. This allows for the kernel to "rightsize" userspace caches for current system-wide workload. Things like image bitmap caches, or rendered HTML in a hidden browser tab, where the data is not visible and can be regenerated if needed, are good examples.

* Opportunistic freeing of memory that may be quickly reused. Minchan has done a malloc implementation where free() marks the pages as volatile, allowing the kernel to reclaim under pressure. This avoids the unmapping and remapping of anonymous pages on free/malloc. So if userland wants to malloc memory quickly after the free, it just needs to mark the pages as non-volatile, and only purged pages will have to be faulted back in.

There are two basic ways this can be used:

Explicit marking method:
1) Userland marks a range of memory that can be regenerated if necessary as volatile
2) Before accessing the memory again, userland marks the memory as nonvolatile, and the kernel will provide notification if any pages in the range has been purged.

Optimistic method:
1) Userland marks a large range of data as volatile
2) Userland continues to access the data as it needs.
3) If userland accesses a page that has been purged, the kernel will send a SIGBUS
4) Userspace can trap the SIGBUS, mark the affected pages as non-volatile, and refill the data as needed before continuing on

You can read more about the history of volatile ranges here:
http://permalink.gmane.org/gmane.linux.kernel.mm/98848
http://permalink.gmane.org/gmane.linux.kernel.mm/98676
https://lwn.net/Articles/522135/
https://lwn.net/Kernel/Index/#Volatile_ranges

This version of the patchset, at Johannes Weiner's suggestion, is much reduced in scope compared to earlier attempts. I've only handled volatility on anonymous memory, and we're storing the volatility in the VMA. This may have performance implications compared with the earlier approach, but it does simplify the approach.

Further, the page discarding happens via normal vmscanning, which due to anonymous pages not being aged on swapless systems, means we'll only purge pages when swap is enabled. I'll be looking at enabling anonymous aging when swap is disabled to resolve this, but I wanted to get this out for initial comment.

Additionally, since we don't handle volatility on tmpfs files with this version of the patch, it is not able to be used to implement semantics similar to Android's ashmem. But since shared volatiltiy on files is more complex, my hope is to start small and hopefully grow from there.

Also, much of the logic in this patchset is based on Minchan's earlier efforts. On this iteration, I've not been in close collaboration with him, so I don't want to mis-attribute my rework of the code as his design, but I do want to make sure the credit goes to him for his major contribution.

Cc Andrew Morton <[email protected]>

Cc Android Kernel Team <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc Robert Love <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Dave Hansen <[email protected]>

Cc Rik van Riel <[email protected]>

Cc Dmitry Adamushko <[email protected]>

Cc Neil Brown <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Mike Hommey <[email protected]>

Cc Taras Glek <[email protected]>

Cc Dhaval Giani <[email protected]>

Cc Jan Kara <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc Michel Lespinasse <[email protected]>

Cc Minchan Kim <[email protected]>

Cc [email protected] <[email protected]>

John Stultz (3):
vrange: Add vrange syscall and handle splitting/merging and marking
vmas
vrange: Add purged page detection on setting memory non-volatile
vrange: Add page purging logic & SIGBUS trap

 arch/x86/syscalls/syscall_64.tbl |   1 +
 include/linux/mm.h               |   1 +
 include/linux/swap.h             |  15 +-
 include/linux/vrange.h           |  22 +++
 mm/Makefile                      |   2 +-
 mm/internal.h                    |   2 -
 mm/memory.c                      |  21 +++
 mm/rmap.c                        |   5 +
 mm/vmscan.c                      |  12 ++
 mm/vrange.c                      | 306 +++++++++++++++++++++++++++++++++++++++
 10 files changed, 382 insertions(+), 5 deletions(-)
 create mode 100644 include/linux/vrange.h
 create mode 100644 mm/vrange.c

Signature · 7 lines

1.8.3.2

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

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

2) Accouting

The one of problem I have thought is lack of accouting of vrange pages. I mean we need some statistics for vrange pages and it should be number of pages rather than vma size. Without that, user space couldn't see current status and then they couldn't control the system's memory consumption. It's alredy known problem for other OS which have support similar thing(ex, MADV_FREE).

For accouting, we should account how many of existing pages are the range when vrange syscall is called. It could increase syscall overhead but user could have accurate statistics information. It's just trade-off.

3) Aging

I think vrange pages should be discarded eariler than other hot pages so want to move pages to tail of inactive LRU when syscall is called. We could do by using deactivate_page with some tweak while we accouts pages in syscall context.

But if user want to treat vrange pages with other hot pages equally he could ask so that we could skip deactivating.

vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO|VRANGE_AGING, &purged) or
vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL|VRANGE_AGING, &purged)

It could be convenient for Moz usecase if they want to age vrange pages.

4) Permanency

Like MCL_FUTURE of mlockall, it would be better to make the range have permanent property until called VRANGE_NOVOLATILE. I mean pages faulted on the range in future since syscall is called should be volatile automatically so that user could avoid frequent syscall to make them volatile.

Quoted 8 lines · Minchan Kim

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

So, the zero-fill on volatile access feels like a *very* special case to me, since a null page could be valid data in many cases. Since support/interest for volatile ranges has been middling at best, I want to start culling the stranger use cases. I'm open in the future to adding a special flag or something if it really make sense, but at this point, lets just get the more general volatile range use cases supported.

Quoted 11 lines

2) Accouting

The one of problem I have thought is lack of accouting of vrange pages. I mean we need some statistics for vrange pages and it should be number of pages rather than vma size. Without that, user space couldn't see current status and then they couldn't control the system's memory consumption. It's alredy known problem for other OS which have support similar thing(ex, MADV_FREE).

Quoted 3 lines

For accouting, we should account how many of existing pages are the range when vrange syscall is called. It could increase syscall overhead but user could have accurate statistics information. It's just trade-off.

Agreed. As I've been looking at handling anonymous page aging on swapless systems, the naive method causes performance issues as we scan and scan and scan the anonymous list trying to page things out to nowhere. Providing the number of volatile pages would allow the scanning to stop at a sensible time.

Quoted 10 lines

3) Aging

I think vrange pages should be discarded eariler than other hot pages so want to move pages to tail of inactive LRU when syscall is called. We could do by using deactivate_page with some tweak while we accouts pages in syscall context.

But if user want to treat vrange pages with other hot pages equally he could ask so that we could skip deactivating.

Quoted 6 lines

vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO|VRANGE_AGING, &purged) or
vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL|VRANGE_AGING, &purged)

It could be convenient for Moz usecase if they want to age vrange pages.

Again, I want to keep the scope small for now, so I'd rather not add more options just yet. I think we should come up with a sensable default and give that time to be used, and if there need to be more options later, we can open those up. I think activating on volatile (so the pages are purged together) is the right default approach, but I'm open to discuss this further.

Quoted 4 lines

4) Permanency

Quoted 5 lines

Like MCL_FUTURE of mlockall, it would be better to make the range have permanent property until called VRANGE_NOVOLATILE. I mean pages faulted on the range in future since syscall is called should be volatile automatically so that user could avoid frequent syscall to make them volatile.

I'm not sure I followed this. Is this with respect to the issue of unmapped holes in the range?

thanks
-john

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

Quoted 10 lines · John Stultz

Quoted 8 lines · Minchan Kim

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

Quoted 7 lines

So, the zero-fill on volatile access feels like a *very* special case to me, since a null page could be valid data in many cases. Since support/interest for volatile ranges has been middling at best, I want to start culling the stranger use cases. I'm open in the future to adding a special flag or something if it really make sense, but at this point, lets just get the more general volatile range use cases supported.

I'm not sure it's special case. Because some user could reserve a big volatile VMA and want to use the range by circle queue for caching so overwriting could happen easily.
We should call vrange(NOVOLATILE) to prevent SIGBUS right before overwriting. I feel it's unnecessary overhead and we could avoid the cost with VRANGE_ZERO.
Do you think this usecase would be rare?

Quoted 19 lines · Minchan Kim

Quoted 10 lines · John Stultz

Quoted 8 lines · Minchan Kim

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

Quoted 7 lines

So, the zero-fill on volatile access feels like a *very* special case to me, since a null page could be valid data in many cases. Since support/interest for volatile ranges has been middling at best, I want to start culling the stranger use cases. I'm open in the future to adding a special flag or something if it really make sense, but at this point, lets just get the more general volatile range use cases supported.

Quoted 7 lines

I'm not sure it's special case. Because some user could reserve a big volatile VMA and want to use the range by circle queue for caching so overwriting could happen easily.
We should call vrange(NOVOLATILE) to prevent SIGBUS right before overwriting. I feel it's unnecessary overhead and we could avoid the cost with VRANGE_ZERO.
Do you think this usecase would be rare?

If I understand it correctly the buffer would be volatile all the time
and userspace would like to opportunistically access it. Hum, but then with your automatic zero-filling it could see half of the page with data and half of the page zeroed out (the page got evicted in the middle of userspace reading it). I don't think that's a very comfortable interface to work with (you would have to very carefully verify the data you've read is really valid). And frankly in most cases I'm afraid the application would fail to do proper verification and crash randomly under memory pressure. So I wouldn't provide VRANGE_ZERO unless I come across real people for which avoiding marking the range as NONVOLATILE is a big deal and they are OK with handling all the odd situations that can happen.

That being said I agree with you that it makes sense to extend the syscall with flags argument so that we have some room for different modifications of the functionality.

Honza

Signature · 8 lines

Jan Kara <[email protected]>
SUSE Labs, CR

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

Hello,

Quoted 27 lines · Jan Kara

Quoted 19 lines · Minchan Kim

Quoted 10 lines · John Stultz

Quoted 8 lines · Minchan Kim

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

Quoted 7 lines

So, the zero-fill on volatile access feels like a *very* special case to me, since a null page could be valid data in many cases. Since support/interest for volatile ranges has been middling at best, I want to start culling the stranger use cases. I'm open in the future to adding a special flag or something if it really make sense, but at this point, lets just get the more general volatile range use cases supported.

Quoted 7 lines

I'm not sure it's special case. Because some user could reserve a big volatile VMA and want to use the range by circle queue for caching so overwriting could happen easily.
We should call vrange(NOVOLATILE) to prevent SIGBUS right before overwriting. I feel it's unnecessary overhead and we could avoid the cost with VRANGE_ZERO.
Do you think this usecase would be rare?

Quoted 11 lines

If I understand it correctly the buffer would be volatile all the time
and userspace would like to opportunistically access it. Hum, but then with your automatic zero-filling it could see half of the page with data and half of the page zeroed out (the page got evicted in the middle of userspace reading it). I don't think that's a very comfortable interface to work with (you would have to very carefully verify the data you've read is really valid). And frankly in most cases I'm afraid the application would fail to do proper verification and crash randomly under memory pressure. So I wouldn't provide VRANGE_ZERO unless I come across real people for which avoiding marking the range as NONVOLATILE is a big deal and they are OK with handling all the odd situations that can happen.

Plaes think following usecase.

Let's assume big volatile cacne.
If there is request for cache, it should find a object in a cache and if it found, it should call vrange(NOVOLATILE) right before passing it to the user and investigate it was purged or not. If it wasn't purged, cache manager could pass the object to the user. But it's circular cache so if there is no request from user, cache manager always overwrites objects so it could encounter SIGBUS easily so as current sematic, cache manager always should call vrange(NOVOLATILE) right before the overwriting. Otherwise, it should register SIGBUS handler to unmark volatile by page unit. SIGH.

If we support VRANGE_ZERO, cache manager could overwrite object without SIGBUS handling or vrange(NOVOLATILE) call. Just need is vrange(NOVOLATILE) call while cache manager pass it to the user.

Quoted 55 lines · Minchan Kim

Hello,

Quoted 27 lines · Jan Kara

Quoted 19 lines · Minchan Kim

Quoted 10 lines · John Stultz

Quoted 8 lines · Minchan Kim

1) SIGBUS

It's one of the arguable issue because some user want to get a SIGBUS(ex, Firefox) while other want a just zero page(ex, Google address sanitizer) without signal so it should be option.

        int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
        int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);

Quoted 7 lines

So, the zero-fill on volatile access feels like a *very* special case to me, since a null page could be valid data in many cases. Since support/interest for volatile ranges has been middling at best, I want to start culling the stranger use cases. I'm open in the future to adding a special flag or something if it really make sense, but at this point, lets just get the more general volatile range use cases supported.

Quoted 7 lines

I'm not sure it's special case. Because some user could reserve a big volatile VMA and want to use the range by circle queue for caching so overwriting could happen easily.
We should call vrange(NOVOLATILE) to prevent SIGBUS right before overwriting. I feel it's unnecessary overhead and we could avoid the cost with VRANGE_ZERO.
Do you think this usecase would be rare?

Quoted 11 lines

If I understand it correctly the buffer would be volatile all the time
and userspace would like to opportunistically access it. Hum, but then with your automatic zero-filling it could see half of the page with data and half of the page zeroed out (the page got evicted in the middle of userspace reading it). I don't think that's a very comfortable interface to work with (you would have to very carefully verify the data you've read is really valid). And frankly in most cases I'm afraid the application would fail to do proper verification and crash randomly under memory pressure. So I wouldn't provide VRANGE_ZERO unless I come across real people for which avoiding marking the range as NONVOLATILE is a big deal and they are OK with handling all the odd situations that can happen.

Plaes think following usecase.

Let's assume big volatile cacne.
If there is request for cache, it should find a object in a cache and if it found, it should call vrange(NOVOLATILE) right before passing it to the user and investigate it was purged or not. If it wasn't purged, cache manager could pass the object to the user. But it's circular cache so if there is no request from user, cache manager always overwrites objects so it could encounter SIGBUS easily so as current sematic, cache manager always should call vrange(NOVOLATILE) right before the overwriting. Otherwise, it should register SIGBUS handler to unmark volatile by page unit. SIGH.

Quoted 3 lines

If we support VRANGE_ZERO, cache manager could overwrite object without SIGBUS handling or vrange(NOVOLATILE) call. Just need is vrange(NOVOLATILE) call while cache manager pass it to the user.

OK, that makes some sense but I don't think we have to implement this
functionality in the beginning...

Honza

Signature · 8 lines

Jan Kara <[email protected]>
SUSE Labs, CR

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