mm: make madvise(MADV_WILLNEED) support swap file prefetch

PATCH In review Shaohua Li 5 participants 12 messages Jan 7, 2013 – Jan 9, 2013 1 message not in the archive

Subsystems (2)

Memory management madvise

lore

Share & tools

lore

Shaohua Li

author

2013-01-07 08:12 UTC #0 lore raw

PATCH 1/1 mm: make madvise(MADV_WILLNEED) support swap file prefetch

Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.

Signed-off-by Shaohua Li <[email protected]>

---
 mm/madvise.c |   94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 94 insertions(+)

mm/madvise.c +94 -0

Index: linux/mm/madvise.c
===================================================================
@@ -16,6 +16,9 @@
 #include <linux/ksm.h>
 #include <linux/fs.h>
 #include <linux/file.h>
+#include <linux/blkdev.h>
+#include <linux/swap.h>
+#include <linux/swapops.h>
 
 /*
  * Any behaviour which results in changes to the vma->vm_flags needs to

@@ -131,6 +134,82 @@ out:
 	return error;
 }
 
+static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start,
+	unsigned long end, struct mm_walk *walk)
+{
+	pte_t *orig_pte;
+	struct vm_area_struct *vma = walk->private;
+	unsigned long index;
+
+	if (pmd_none_or_trans_huge_or_clear_bad(pmd))
+		return 0;
+
+	for (index = start; index != end; index += PAGE_SIZE) {
+		pte_t pte;
+		swp_entry_t entry;
+		struct page *page;
+		spinlock_t *ptl;
+
+		orig_pte = pte_offset_map_lock(vma->vm_mm, pmd, start, &ptl);
+		pte = *(orig_pte + ((index - start) / PAGE_SIZE));
+		pte_unmap_unlock(orig_pte, ptl);
+
+		if (pte_present(pte) || pte_none(pte) || pte_file(pte))
+			continue;
+		entry = pte_to_swp_entry(pte);
+		if (unlikely(non_swap_entry(entry)))
+			continue;
+
+		page = read_swap_cache_async(entry, GFP_HIGHUSER_MOVABLE,
+								vma, index);
+		if (page)
+			page_cache_release(page);
+	}
+
+	return 0;
+}
+
+static void force_swapin_readahead(struct vm_area_struct *vma,
+		unsigned long start, unsigned long end)
+{
+	struct mm_walk walk = {
+		.mm = vma->vm_mm,
+		.pmd_entry = swapin_walk_pmd_entry,
+		.private = vma,
+	};
+
+	walk_page_range(start, end, &walk);
+
+	lru_add_drain();	/* Push any new pages onto the LRU now */
+}
+
+static void force_shm_swapin_readahead(struct vm_area_struct *vma,
+		unsigned long start, unsigned long end,
+		struct address_space *mapping)
+{
+	pgoff_t index;
+	struct page *page;
+	swp_entry_t swap;
+
+	for (; start < end; start += PAGE_SIZE) {
+		index = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+
+		page = find_get_page(mapping, index);
+		if (!radix_tree_exceptional_entry(page)) {
+			if (page)
+				page_cache_release(page);
+			continue;
+		}
+		swap = radix_to_swp_entry(page);
+		page = read_swap_cache_async(swap, GFP_HIGHUSER_MOVABLE,
+								NULL, 0);
+		if (page)
+			page_cache_release(page);
+	}
+
+	lru_add_drain();	/* Push any new pages onto the LRU now */
+}
+
 /*
  * Schedule all required I/O operations.  Do not wait for completion.
  */

@@ -140,6 +219,18 @@ static long madvise_willneed(struct vm_a
 {
 	struct file *file = vma->vm_file;
 
+#ifdef CONFIG_SWAP
+	if (!file || mapping_cap_swap_backed(file->f_mapping)) {
+		*prev = vma;
+		if (!file)
+			force_swapin_readahead(vma, start, end);
+		else
+			force_shm_swapin_readahead(vma, start, end,
+						file->f_mapping);
+		return 0;
+	}
+#endif
+
 	if (!file)
 		return -EBADF;

@@ -371,6 +462,7 @@ SYSCALL_DEFINE3(madvise, unsigned long,
 	int error = -EINVAL;
 	int write;
 	size_t len;
+	struct blk_plug plug;
 
 #ifdef CONFIG_MEMORY_FAILURE
 	if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE)

@@ -410,6 +502,7 @@ SYSCALL_DEFINE3(madvise, unsigned long,
 	if (vma && start > vma->vm_start)
 		prev = vma;
 
+	blk_start_plug(&plug);
 	for (;;) {
 		/* Still start < end. */
 		error = -ENOMEM;

@@ -445,6 +538,7 @@ SYSCALL_DEFINE3(madvise, unsigned long,
 			vma = find_vma(current->mm, start);
 	}
 out:
+	blk_finish_plug(&plug);
 	if (write)
 		up_write(&current->mm->mmap_sem);
 	else

--
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>

Andrew Morton

maintainer

2013-01-07 20:06 UTC #1 lore raw

Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:

Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.

Seems sensible.

Review static long madvise_willneed(struct vm_a · line 222

Quoted 5 lines

(quoted diff) +1 -0

@@ -140,6 +219,18 @@ static long madvise_willneed(struct vm_a
 {
 	struct file *file = vma->vm_file;
 
+#ifdef CONFIG_SWAP

It's odd that you put the ifdef in there, but then didn't test it!

From: Andrew Morton <[email protected]>
Subject: mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix

fix CONFIG_SWAP=n build

Cc Shaohua Li <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Rik van Riel <[email protected]>

Signed-off-by Andrew Morton <[email protected]>

---

 mm/madvise.c |    2 ++
 1 file changed, 2 insertions(+)

mm/madvise.c renamed from mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix +2 -0

diff -puN mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix mm/madvise.c
@@ -134,6 +134,7 @@ out:
 	return error;
 }
 
+#ifdef CONFIG_SWAP
 static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start,
 	unsigned long end, struct mm_walk *walk)
 {

@@ -209,6 +210,7 @@ static void force_shm_swapin_readahead(s
 
 	lru_add_drain();	/* Push any new pages onto the LRU now */
 }
+#endif		/* CONFIG_SWAP */
 
 /*
  * Schedule all required I/O operations.  Do not wait for completion.

Wanpeng Li

2013-01-08 02:16 UTC #2 lore raw

Quoted 9 lines · Andrew Morton

Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.

Hi Andrew and Shaohua,

What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.

Regards,
Wanpeng Li

Quoted 45 lines

mm/madvise.c static long madvise_willneed(struct vm_a · line 222
Quoted 6 lines
mm/madvise.c renamed from mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix +1 -0
@@ -140,6 +219,18 @@ static long madvise_willneed(struct vm_a
 {
 	struct file *file = vma->vm_file;
 
+#ifdef CONFIG_SWAP
It's odd that you put the ifdef in there, but then didn't test it!
From: Andrew Morton <[email protected]>
Subject: mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix
fix CONFIG_SWAP=n build
Cc Shaohua Li <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Rik van Riel <[email protected]>
Signed-off-by Andrew Morton <[email protected]>
---
mm/madvise.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix mm/madvise.c
mm/madvise.c renamed from mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix +2 -0
@@ -134,6 +134,7 @@ out:
 	return error;
 }
 
+#ifdef CONFIG_SWAP
 static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start,
 	unsigned long end, struct mm_walk *walk)
 {
@@ -209,6 +210,7 @@ static void force_shm_swapin_readahead(s
 
 	lru_add_drain();	/* Push any new pages onto the LRU now */
 }
+#endif		/* CONFIG_SWAP */
 
 /*
 * Schedule all required I/O operations.  Do not wait for completion.
_

Quoted 5 lines

--
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>

Wanpeng Li

2013-01-08 02:16 UTC #3 lore raw

In reply to Andrew Morton

Quoted 9 lines · Andrew Morton

Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.

Hi Andrew and Shaohua,

Regards,
Wanpeng Li

Quoted 45 lines

mm/madvise.c static long madvise_willneed(struct vm_a · line 222
Quoted 6 lines
mm/madvise.c renamed from mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix +1 -0
@@ -140,6 +219,18 @@ static long madvise_willneed(struct vm_a
 {
 	struct file *file = vma->vm_file;
 
+#ifdef CONFIG_SWAP
It's odd that you put the ifdef in there, but then didn't test it!
From: Andrew Morton <[email protected]>
Subject: mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix
fix CONFIG_SWAP=n build
Cc Shaohua Li <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Rik van Riel <[email protected]>
Signed-off-by Andrew Morton <[email protected]>
---
mm/madvise.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix mm/madvise.c
mm/madvise.c renamed from mm/madvise.c~mm-make-madvisemadv_willneed-support-swap-file-prefetch-fix +2 -0
@@ -134,6 +134,7 @@ out:
 	return error;
 }
 
+#ifdef CONFIG_SWAP
 static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start,
 	unsigned long end, struct mm_walk *walk)
 {
@@ -209,6 +210,7 @@ static void force_shm_swapin_readahead(s
 
 	lru_add_drain();	/* Push any new pages onto the LRU now */
 }
+#endif		/* CONFIG_SWAP */
 
 /*
 * Schedule all required I/O operations.  Do not wait for completion.
_

Quoted 5 lines

--
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>

Shaohua Li

author

2013-01-08 04:26 UTC #5 lore raw

In reply to a message not in the archive

Quoted 9 lines · Wanpeng Li

Quoted 8 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.

Quoted 8 lines

Quoted 1 line
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.

pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.

Another advantage is prefetch can drive high disk iodepth. For sequential access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.

Thanks,
Shaohua

Minchan Kim

2013-01-08 05:38 UTC #6 lore raw

Hi Shaohua,

Quoted 19 lines · Shaohua Li

Quoted 9 lines · Wanpeng Li
Quoted 8 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Quoted 8 lines
Quoted 1 line
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.

Quoted 4 lines

pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.

How can you make sure that the range of WILLNEED was always sequentially accesssed?

Quoted 2 lines

Another advantage is prefetch can drive high disk iodepth. For sequential

What does it mean 'iodepth'? I failed to grep it in google. :(

Quoted 2 lines

access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.

So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?

Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.

Quoted 9 lines

Thanks,
Shaohua
--
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>

Signature · 8 lines

Kind regards,
Minchan Kim

--
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>

Shaohua Li

author

2013-01-08 07:32 UTC #7 lore raw

Quoted 22 lines · Minchan Kim

Hi Shaohua,
Quoted 19 lines · Shaohua Li
Quoted 17 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.

Quoted 6 lines

Quoted 4 lines
pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
How can you make sure that the range of WILLNEED was always sequentially accesssed?

you can't guarantee this even for file access.

Quoted 3 lines

Quoted 1 line
Another advantage is prefetch can drive high disk iodepth. For sequential
What does it mean 'iodepth'? I failed to grep it in google. :(

io depth. How many requests are inflight at a givin time.

Quoted 5 lines

Quoted 2 lines
access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.
So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?

Hmm, even for hard disk, high iodepth random access is faster than single iodepth access. Today's disk is NCQ disk. But the speedup isn't that significant like a SSD. For sequential access, both harddisk and SSD have better performance with higher iodepth.

Quoted 2 lines

Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.

I would, but the question is just like why app wants to prefetch file pages. I thought it's commonsense. The problem like memory allocation exists in file prefetch too. The advantages (better IO access, CPU and disk can operate in parallel and so on) apply for both file and swap prefetch.

prefetch should never be slower non-prefetch. That's another story if app is very wrong. we definitely don't need consider a wrong app. If the app doesn't know how to use the API, the app can just don't use it.

Thanks,
Shaohua

Simon Jeons

2013-01-08 07:55 UTC #8 lore raw

Quoted 49 lines · Shaohua Li

Quoted 22 lines · Minchan Kim
Hi Shaohua,
Quoted 19 lines · Shaohua Li
Quoted 17 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.
Quoted 6 lines
Quoted 4 lines
pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
How can you make sure that the range of WILLNEED was always sequentially accesssed?
you can't guarantee this even for file access.
Quoted 3 lines
Quoted 1 line
Another advantage is prefetch can drive high disk iodepth. For sequential
What does it mean 'iodepth'? I failed to grep it in google. :(
io depth. How many requests are inflight at a givin time.
Quoted 5 lines
Quoted 2 lines
access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.
So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?
Hmm, even for hard disk, high iodepth random access is faster than single iodepth access. Today's disk is NCQ disk. But the speedup isn't that significant like a SSD. For sequential access, both harddisk and SSD have better performance with higher iodepth.

Quoted 5 lines

Quoted 2 lines
Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.
I would, but the question is just like why app wants to prefetch file pages. I thought it's commonsense. The problem like memory allocation exists in file

It just depends on how you understand it. :)

Quoted 7 lines

prefetch too. The advantages (better IO access, CPU and disk can operate in parallel and so on) apply for both file and swap prefetch.
prefetch should never be slower non-prefetch. That's another story if app is very wrong. we definitely don't need consider a wrong app. If the app doesn't know how to use the API, the app can just don't use it.

Quoted 8 lines

Thanks,
Shaohua
--
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>

Minchan Kim

2013-01-08 08:38 UTC #9 lore raw

In reply to Shaohua Li

Quoted 23 lines · Shaohua Li

Quoted 22 lines · Minchan Kim
Hi Shaohua,
Quoted 19 lines · Shaohua Li
Quoted 17 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
How can you make sure that the range of WILLNEED was always sequentially accesssed?
you can't guarantee this even for file access.

Indeed.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
Another advantage is prefetch can drive high disk iodepth. For sequential
What does it mean 'iodepth'? I failed to grep it in google. :(
io depth. How many requests are inflight at a givin time.

Thanks for the info!

Quoted 12 lines

Quoted 6 lines
Quoted 3 lines
access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.
So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?
Hmm, even for hard disk, high iodepth random access is faster than single iodepth access. Today's disk is NCQ disk. But the speedup isn't that significant like a SSD. For sequential access, both harddisk and SSD have better performance with higher iodepth.

Quoted 7 lines

Quoted 2 lines
Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.
I would, but the question is just like why app wants to prefetch file pages. I thought it's commonsense. The problem like memory allocation exists in file prefetch too. The advantages (better IO access, CPU and disk can operate in parallel and so on) apply for both file and swap prefetch.

Agreed. But I have a question about semantic of madvise(DONTNEED) of anon vma. If Linux start to support it for anon, user can misunderstand it following as.

User might think we start to use anonymous pages in that range soon so he gives the hint to kernel to map all pages of the range to page table in advance. (ie, pre page fault like MAP_POPULATE) and if one of the page might be swapped out, readahead it. What do you think about it?
For clarification, it would be better to add man page description with Ccing man page maintainer.

Quoted 4 lines

prefetch should never be slower non-prefetch. That's another story if app is very wrong. we definitely don't need consider a wrong app. If the app doesn't know how to use the API, the app can just don't use it.

Fair enough.

Quoted 9 lines

Thanks,
Shaohua
--
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>

Signature · 8 lines

Kind regards,
Minchan Kim

--
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>

Simon Jeons

2013-01-08 08:45 UTC #12 lore raw

In reply to Shaohua Li

Quoted 12 lines · Shaohua Li

Quoted 11 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.

Quoted 8 lines

Quoted 6 lines
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.
pages in swap are not highly fragmented if you access memory sequentially. In

In the scenario of serious memory pressure, pages swapin and swapout frequently, how to guarantee swap area is not fragmented?

Quoted 8 lines

that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
Another advantage is prefetch can drive high disk iodepth. For sequential access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.

Quoted 8 lines

Thanks,
Shaohua
--
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>

Shaohua Li

author

2013-01-08 09:13 UTC #10 lore raw

In reply to Minchan Kim

Quoted 67 lines · Minchan Kim

Quoted 23 lines · Shaohua Li
Quoted 22 lines · Minchan Kim
Hi Shaohua,
Quoted 19 lines · Shaohua Li
Quoted 17 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
How can you make sure that the range of WILLNEED was always sequentially accesssed?
you can't guarantee this even for file access.
Indeed.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Another advantage is prefetch can drive high disk iodepth. For sequential
What does it mean 'iodepth'? I failed to grep it in google. :(
io depth. How many requests are inflight at a givin time.
Thanks for the info!
Quoted 12 lines
Quoted 6 lines
Quoted 3 lines
access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.
So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?
Hmm, even for hard disk, high iodepth random access is faster than single iodepth access. Today's disk is NCQ disk. But the speedup isn't that significant like a SSD. For sequential access, both harddisk and SSD have better performance with higher iodepth.
Quoted 7 lines
Quoted 2 lines
Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.
I would, but the question is just like why app wants to prefetch file pages. I thought it's commonsense. The problem like memory allocation exists in file prefetch too. The advantages (better IO access, CPU and disk can operate in parallel and so on) apply for both file and swap prefetch.
Agreed. But I have a question about semantic of madvise(DONTNEED) of anon vma. If Linux start to support it for anon, user can misunderstand it following as.

Quoted 6 lines

User might think we start to use anonymous pages in that range soon so he gives the hint to kernel to map all pages of the range to page table in advance. (ie, pre page fault like MAP_POPULATE) and if one of the page might be swapped out, readahead it. What do you think about it?
For clarification, it would be better to add man page description with Ccing man page maintainer.

there is no confusion if the page exists or swapped. I thought what you are are thinking about is the page isn't populated yet. The manpage declaims WILLNEED "it might be a good idea to read some pages ahead." This sounds clear this isn't to populate memory and matches what we did. But I'm not sure what's the precise description.

Thanks,
Shaohua

Minchan Kim

2013-01-09 07:28 UTC #11 lore raw

Quoted 75 lines · Shaohua Li

Quoted 67 lines · Minchan Kim
Quoted 23 lines · Shaohua Li
Quoted 22 lines · Minchan Kim
Hi Shaohua,
Quoted 19 lines · Shaohua Li
Quoted 17 lines · Wanpeng Li
Quoted 9 lines · Andrew Morton
Quoted 4 lines · On Mon, 7 Jan 2013 16:12:37 +0800 Shaohua Li <[email protected]> wrote:
Make madvise(MADV_WILLNEED) support swap file prefetch. If memory is swapout, this syscall can do swapin prefetch. It has no impact if the memory isn't swapout.
Seems sensible.
Hi Andrew and Shaohua,
What's the performance in the scenario of serious memory pressure? Since in this case pages in swap are highly fragmented and cache hit is most impossible. If WILLNEED path should add a check to skip readahead in this case since swapin only leads to unnecessary memory allocation.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
pages in swap are not highly fragmented if you access memory sequentially. In that case, the pages you accessed will be added to lru list side by side. So if app does swap prefetch, we can do sequential disk access and merge small request to big one.
How can you make sure that the range of WILLNEED was always sequentially accesssed?
you can't guarantee this even for file access.
Indeed.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
Another advantage is prefetch can drive high disk iodepth. For sequential
What does it mean 'iodepth'? I failed to grep it in google. :(
io depth. How many requests are inflight at a givin time.
Thanks for the info!
Quoted 12 lines
Quoted 6 lines
Quoted 3 lines
access, this can cause big request. Even for random access, high iodepth has much better performance especially for SSD.
So you mean WILLNEED is always good in where both random and sequential in "SSD"? Then, how about the "Disk"?
Hmm, even for hard disk, high iodepth random access is faster than single iodepth access. Today's disk is NCQ disk. But the speedup isn't that significant like a SSD. For sequential access, both harddisk and SSD have better performance with higher iodepth.
Quoted 7 lines
Quoted 2 lines
Wanpeng's comment makes sense to me so I guess others can have a same question about this patch. So it would be better to write your rationale in changelog.
I would, but the question is just like why app wants to prefetch file pages. I thought it's commonsense. The problem like memory allocation exists in file prefetch too. The advantages (better IO access, CPU and disk can operate in parallel and so on) apply for both file and swap prefetch.
Agreed. But I have a question about semantic of madvise(DONTNEED) of anon vma. If Linux start to support it for anon, user can misunderstand it following as.
Quoted 6 lines
User might think we start to use anonymous pages in that range soon so he gives the hint to kernel to map all pages of the range to page table in advance. (ie, pre page fault like MAP_POPULATE) and if one of the page might be swapped out, readahead it. What do you think about it?
For clarification, it would be better to add man page description with Ccing man page maintainer.

Quoted 5 lines

there is no confusion if the page exists or swapped. I thought what you are are thinking about is the page isn't populated yet. The manpage declaims WILLNEED "it might be a good idea to read some pages ahead." This sounds clear this isn't to populate memory and matches what we did. But I'm not sure what's the precise description.

Anyway, you are adding new feature.
For merging, we need a real practice scenario, gain and exact semantics for man pages. I don't know why current Linux man pages is very poor about WILLNEED. If it doesn't give enough information for user to expect system's behavior, anyone doesn't want to use it.
POV perforance, Ccing Johannes because he tried similar long time ago so he might have a comment.

Quoted 9 lines

Thanks,
Shaohua
--
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>

Signature · 8 lines

Kind regards,
Minchan Kim

--
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>