MADV_FREE support

Linux doesn't have an ability to free pages lazy while other OS already have been supported that named by madvise(MADV_FREE).

The gain is clear that kernel can discard freed pages rather than swapping out or OOM if memory pressure happens.

Without memory pressure, freed pages would be reused by userspace without another additional overhead(ex, page fault + allocation
+ zeroing).

How to work is following as.

When madvise syscall is called, VM clears dirty bit of ptes of the range. If memory pressure happens, VM checks dirty bit of page table and if it found still "clean", it means it's a "lazyfree pages" so VM could discard the page instead of swapping out. Once there was store operation for the page before VM peek a page to reclaim, dirty bit is set so VM can swap out the page instead of discarding.

Firstly, heavy users would be general allocators(ex, jemalloc, tcmalloc and hope glibc supports it) and jemalloc/tcmalloc already have supported the feature for other OS(ex, FreeBSD)

Cc Michael Kerrisk <[email protected]>

Cc Linux API <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Johannes Weiner <[email protected]>

Cc KOSAKI Motohiro <[email protected]>

Cc Mel Gorman <[email protected]>

Cc Jason Evans <[email protected]>

Acked-by Kirill A. Shutemov <[email protected]>

Acked-by Zhang Yanfei <[email protected]>

Acked-by Rik van Riel <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

[Late but I didn't get to this soone - I hope this is still up-to-date version]

Quoted 12 lines · Minchan Kim

Linux doesn't have an ability to free pages lazy while other OS already have been supported that named by madvise(MADV_FREE).

The gain is clear that kernel can discard freed pages rather than swapping out or OOM if memory pressure happens.

Without memory pressure, freed pages would be reused by userspace without another additional overhead(ex, page fault + allocation
+ zeroing).

How to work is following as.

Quoted 7 lines

When madvise syscall is called, VM clears dirty bit of ptes of the range. If memory pressure happens, VM checks dirty bit of page table and if it found still "clean", it means it's a "lazyfree pages" so VM could discard the page instead of swapping out. Once there was store operation for the page before VM peek a page to reclaim, dirty bit is set so VM can swap out the page instead of discarding.

Is there any patch for madvise man page? I guess the semantic will be same/similar to FreeBSD:
http://www.freebsd.org/cgi/man.cgi?query=madvise&sektion=2

From 2edd6890f92fa4943ce3c452194479458582d88c Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

---
 man2/madvise.2 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

man2/madvise.2 +0 -0

index 032ead7..33aa936 100644

man2/madvise.2 +2 -0

+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

On Mon 01-12-14 08:56:52, Minchan Kim wrote:
[...]

Quoted 20 lines

From 2edd6890f92fa4943ce3c452194479458582d88c Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

---
 man2/madvise.2 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

man2/madvise.2 +2 -0

index 032ead7..33aa936 100644
@@ -265,6 +265,19 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"

man2/madvise.2 file (see · line 273

Quoted 4 lines

man2/madvise.2 +4 -0

+Gives the VM system the freedom to free pages, and tells the system that
+information in the specified page range is no longer important.
+This is an efficient way of allowing
+.BR malloc (3)

This might be rather misleading. Only some malloc implementations are using this feature (jemalloc, right?). So either be specific about which implementation or do not add it at all.

man2/madvise.2 file (see · line 278

Quoted 6 lines

man2/madvise.2 +5 -0

+to free pages anywhere in the address space, while keeping the address space
+valid. The next time that the page is referenced, the page might be demand
+zeroed, or might contain the data that was there before the MADV_FREE call.
+References made to that address space range will not make the VM system page the
+information back in from backing store until the page is modified again.

I am not sure I understand the last sentence. So say I did MADV_FREE and the reclaim has dropped that page. I know that the file backed mappings are not supported yet but assume they were for a second... Now, I do read from that location again what is the result?

If we consider anon mappings then the backing store is misleading as well because memory was dropped and so always newly allocated.

I would rather drop the whole sentence and rather see an explanation what is the difference between to MADV_DONT_NEED.
"
Unlike MADV_DONT_NEED the memory is freed lazily e.g. when the VM system is under memory pressure.
"

Quoted 6 lines

man2/madvise.2 +2 -0

+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

Signature · 8 lines

Michal Hocko
SUSE Labs

--
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 22 lines · Michal Hocko

On Mon 01-12-14 08:56:52, Minchan Kim wrote:
[...]

Quoted 20 lines

From 2edd6890f92fa4943ce3c452194479458582d88c Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

---
 man2/madvise.2 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

man2/madvise.2 +2 -0

index 032ead7..33aa936 100644
@@ -265,6 +265,19 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"

Quoted 8 lines

man2/madvise.2 file (see · line 273

Quoted 4 lines

man2/madvise.2 +4 -0

+Gives the VM system the freedom to free pages, and tells the system that
+information in the specified page range is no longer important.
+This is an efficient way of allowing
+.BR malloc (3)

This might be rather misleading. Only some malloc implementations are using this feature (jemalloc, right?). So either be specific about which implementation or do not add it at all.

Make sense. I don't think it's a good idea to say specific example in man page, which is rather arguable and limit the idea.

Quoted 11 lines

man2/madvise.2 file (see · line 278

Quoted 6 lines

man2/madvise.2 +5 -0

+to free pages anywhere in the address space, while keeping the address space
+valid. The next time that the page is referenced, the page might be demand
+zeroed, or might contain the data that was there before the MADV_FREE call.
+References made to that address space range will not make the VM system page the
+information back in from backing store until the page is modified again.

I am not sure I understand the last sentence. So say I did MADV_FREE and the reclaim has dropped that page. I know that the file backed mappings are not supported yet but assume they were for a second... Now, I do read from that location again what is the result?

Zero page.

Quoted 2 lines

If we consider anon mappings then the backing store is misleading as well because memory was dropped and so always newly allocated.

When I read the sentence at first, I thought backing store means swap so I don't have any trouble to understand it. But I agree your opinion. Target for man page is not a kernel developer but application developer.

Quoted 6 lines

I would rather drop the whole sentence and rather see an explanation what is the difference between to MADV_DONT_NEED.
"
Unlike MADV_DONT_NEED the memory is freed lazily e.g. when the VM system is under memory pressure.
"

It's a good idea but I don't think it's enough. At least we should explan cancel of delay free logic(ie, write). So, How about this?

MADV_FREE " (since Linux 3.19)"

Gives the VM system the freedom to free pages, and tells the system that it's okay to free pages if the VM system has reasons(e.g., memory pressure). So, it looks like delayed MADV_DONTNEED.
The next time that the page is referenced, the page might be demand zeroed if the VM system freed the page. Otherwise, it might contain the data that was there before the MADV_FREE call if the VM system didn't free the page. New write in the page after the MADV_FREE call makes the VM system not free the page any more.

It works only with private anonymous pages (see mmap(2)).

Quoted 47 lines · Minchan Kim

Quoted 22 lines · Michal Hocko

On Mon 01-12-14 08:56:52, Minchan Kim wrote:
[...]

Quoted 20 lines

From 2edd6890f92fa4943ce3c452194479458582d88c Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

---
 man2/madvise.2 | 13 +++++++++++++
 1 file changed, 13 insertions(+)

man2/madvise.2 +2 -0

index 032ead7..33aa936 100644
@@ -265,6 +265,19 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"

Quoted 8 lines

man2/madvise.2 file (see · line 273

Quoted 4 lines

man2/madvise.2 +4 -0

+Gives the VM system the freedom to free pages, and tells the system that
+information in the specified page range is no longer important.
+This is an efficient way of allowing
+.BR malloc (3)

This might be rather misleading. Only some malloc implementations are using this feature (jemalloc, right?). So either be specific about which implementation or do not add it at all.

Make sense. I don't think it's a good idea to say specific example in man page, which is rather arguable and limit the idea.

Quoted 11 lines

man2/madvise.2 file (see · line 278

Quoted 6 lines

man2/madvise.2 +5 -0

+to free pages anywhere in the address space, while keeping the address space
+valid. The next time that the page is referenced, the page might be demand
+zeroed, or might contain the data that was there before the MADV_FREE call.
+References made to that address space range will not make the VM system page the
+information back in from backing store until the page is modified again.

I am not sure I understand the last sentence. So say I did MADV_FREE and the reclaim has dropped that page. I know that the file backed mappings are not supported yet but assume they were for a second... Now, I do read from that location again what is the result?

Quoted 1 line

Zero page.

OK, it felt strange at first but now that I am thinking about it some more it starts making sense. So the semantic is: Either zero page (disconnected from the backing store) or the original content after madvise(MADV_FREE). The page gets connected to the backing store after it gets modified again. If this is the case then the sentence in the man page makes perfect sense.

What made me confused was that I expected file backed pages would get a fresh page from the origin but this would be awkward I guess.

Quoted 19 lines

Quoted 2 lines

If we consider anon mappings then the backing store is misleading as well because memory was dropped and so always newly allocated.

When I read the sentence at first, I thought backing store means swap so I don't have any trouble to understand it. But I agree your opinion. Target for man page is not a kernel developer but application developer.

Quoted 6 lines

I would rather drop the whole sentence and rather see an explanation what is the difference between to MADV_DONT_NEED.
"
Unlike MADV_DONT_NEED the memory is freed lazily e.g. when the VM system is under memory pressure.
"

It's a good idea but I don't think it's enough. At least we should explan cancel of delay free logic(ie, write). So, How about this?

MADV_FREE " (since Linux 3.19)"

Quoted 8 lines

Gives the VM system the freedom to free pages, and tells the system that it's okay to free pages if the VM system has reasons(e.g., memory pressure). So, it looks like delayed MADV_DONTNEED.
The next time that the page is referenced, the page might be demand zeroed if the VM system freed the page. Otherwise, it might contain the data that was there before the MADV_FREE call if the VM system didn't free the page. New write in the page after the MADV_FREE call makes the VM system not free the page any more.

Dunno, I guess the original content was slightly better. Or the following wording from UNIX man pages is even more descriptive
(http://www.lehman.cuny.edu/cgi-bin/man-cgi?madvise+3)
"
Tell the kernel that contents in the specified address range are no longer important and the range will be overwritten. When there is demand for memory, the system will free pages associated with the specified address range. In this instance, the next time a page in the address range is referenced, it will contain all zeroes. Otherwise, it will con- tain the data that was there prior to the MADV_FREE call. References made to the address range will not make the system read from backing store (swap space) until the page is modified again.

This value cannot be used on mappings that have underlying file objects. "

I would just clarify the last sentence with addition (MAP_PRIVATE|MAP_ANONYMOUS mappings in this implementation). The

difference to MADV_DONTNEED is more complicated now so I wouldn't make the text even more confusing.

Anyway the confusion started on my end so feel free to stick with the BSD wording (modulo malloc note which is really confusing as the default glibc allocator doesn't do that AFAIK).

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

---
 man2/madvise.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

man2/madvise.2 +12 -0

index 032ead7..fc1aaca 100644
@@ -265,6 +265,18 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"
+Tell the kernel that contents in the specified address range are no
+longer important and the range will be overwritten. When there is
+demand for memory, the system will free pages associated with the
+specified address range. In this instance, the next time a page in the
+address range is referenced, it will contain all zeroes.  Otherwise,
+it will contain the data that was there prior to the MADV_FREE call.
+References made to the address range will not make the system read
+from backing store (swap space) until the page is modified again.
+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

Signature · 9 lines

2.0.0

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri 05-12-14 16:08:16, Minchan Kim wrote:
[...]

Quoted 6 lines

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Thanks!

Quoted 19 lines

---
 man2/madvise.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

man2/madvise.2 +7 -0

index 032ead7..fc1aaca 100644
@@ -265,6 +265,18 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"
+Tell the kernel that contents in the specified address range are no
+longer important and the range will be overwritten. When there is
+demand for memory, the system will free pages associated with the
+specified address range. In this instance, the next time a page in the
+address range is referenced, it will contain all zeroes.  Otherwise,

man2/madvise.2 file (see · line 282

Quoted 8 lines

man2/madvise.2 +5 -0

+it will contain the data that was there prior to the MADV_FREE call.
+References made to the address range will not make the system read
+from backing store (swap space) until the page is modified again.
+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

Hello Minchan (and Michal)

I did not see this patch until just now when Michael explicitly mentioned it in another discussion because
(a) it was buried in an LMKL thread that started a topic that was not about a man-pages patch.
(b) linux-man@ was not CCed.

When resubmitting this patch, could you please To:me and CC linux-man@ and give the mail a suitable subject line indicating a man-pages patch.

Quoted 32 lines · Minchan Kim

[...]

Quoted 6 lines

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Thanks!

Quoted 19 lines

---
 man2/madvise.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

man2/madvise.2 +7 -0

index 032ead7..fc1aaca 100644
@@ -265,6 +265,18 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"
+Tell the kernel that contents in the specified address range are no
+longer important and the range will be overwritten. When there is
+demand for memory, the system will free pages associated with the
+specified address range. In this instance, the next time a page in the
+address range is referenced, it will contain all zeroes.  Otherwise,

Quoted 8 lines

man2/madvise.2 file (see · line 282

Quoted 8 lines

man2/madvise.2 +5 -0

+it will contain the data that was there prior to the MADV_FREE call.
+References made to the address range will not make the system read
+from backing store (swap space) until the page is modified again.
+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

If I'm reading the conversation right, the initially proposed text was from the BSD man page (which would be okay), but most of the text above seems to have come straight from the page here:
http://www.lehman.cuny.edu/cgi-bin/man-cgi?madvise+3

Right?

Unfortunately, I don't think we can use that text. It's from the Solaris man page as far as I can tell, and I doubt that it's under a license that we can use.

If that's the case, we need to go back and come up with an original text. It might draw inspiration from the Solaris page, and take actual text from the BSD page (which is under a free license), and it might also draw inspiration from Jon Corbet's description at http://lwn.net/Articles/590991/.

Could you take another shot this please!

Thanks,

Michael

Signature · 3 lines

Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Hello, Michael

Quoted 7 lines · Michael Kerrisk (man-pages)

Hello Minchan (and Michal)

I did not see this patch until just now when Michael explicitly mentioned it in another discussion because
(a) it was buried in an LMKL thread that started a topic that was not about a man-pages patch.
(b) linux-man@ was not CCed.

Sorry about that.

Quoted 3 lines

When resubmitting this patch, could you please To:me and CC linux-man@ and give the mail a suitable subject line indicating a man-pages patch.

Sure.

Quoted 48 lines · Michal Hocko

Quoted 32 lines · Minchan Kim

[...]

Quoted 6 lines

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Thanks!

Quoted 19 lines

---
 man2/madvise.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

man2/madvise.2 +7 -0

index 032ead7..fc1aaca 100644
@@ -265,6 +265,18 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"
+Tell the kernel that contents in the specified address range are no
+longer important and the range will be overwritten. When there is
+demand for memory, the system will free pages associated with the
+specified address range. In this instance, the next time a page in the
+address range is referenced, it will contain all zeroes.  Otherwise,

Quoted 8 lines

man2/madvise.2 file (see · line 282

Quoted 8 lines

man2/madvise.2 +5 -0

+it will contain the data that was there prior to the MADV_FREE call.
+References made to the address range will not make the system read
+from backing store (swap space) until the page is modified again.
+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

If I'm reading the conversation right, the initially proposed text was from the BSD man page (which would be okay), but most of the text above seems to have come straight from the page here:
http://www.lehman.cuny.edu/cgi-bin/man-cgi?madvise+3

Quoted 1 line

Right?

True. Solaris man page was really straightforward/clear rather than BSD.

Quoted 5 lines

Unfortunately, I don't think we can use that text. It's from the Solaris man page as far as I can tell, and I doubt that it's under a license that we can use.

Quoted 7 lines

If that's the case, we need to go back and come up with an original text. It might draw inspiration from the Solaris page, and take actual text from the BSD page (which is under a free license), and it might also draw inspiration from Jon Corbet's description at http://lwn.net/Articles/590991/.

Could you take another shot this please!

No problem. I will test my essay writing skill.
Thanks.

Quoted 3 lines

Thanks,

Quoted 8 lines

Michael

Signature · 3 lines

Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

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>

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

slightly to make it work without swap), I got oom. If swap is enabled, my

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

Thanks,
Shaohua

Quoted 108 lines · Minchan Kim

Hello, Michael

Quoted 7 lines · Michael Kerrisk (man-pages)

Hello Minchan (and Michal)

I did not see this patch until just now when Michael explicitly mentioned it in another discussion because
(a) it was buried in an LMKL thread that started a topic that was not about a man-pages patch.
(b) linux-man@ was not CCed.

Sorry about that.

Quoted 3 lines

When resubmitting this patch, could you please To:me and CC linux-man@ and give the mail a suitable subject line indicating a man-pages patch.

Sure.

Quoted 48 lines · Michal Hocko

Quoted 32 lines · Minchan Kim

[...]

Quoted 6 lines

From cfa212d4fb307ae772b08cf564cab7e6adb8f4fc Mon Sep 17 00:00:00 2001
From: Minchan Kim <[email protected]>
Date: Mon, 1 Dec 2014 08:53:55 +0900
Subject: [PATCH] madvise.2: Document MADV_FREE

Signed-off-by Minchan Kim <[email protected]>

Reviewed-by Michal Hocko <[email protected]>

Thanks!

Quoted 19 lines

---
 man2/madvise.2 | 12 ++++++++++++
 1 file changed, 12 insertions(+)

man2/madvise.2 +7 -0

index 032ead7..fc1aaca 100644
@@ -265,6 +265,18 @@ file (see
 .BR MADV_DODUMP " (since Linux 3.4)"
 Undo the effect of an earlier
 .BR MADV_DONTDUMP .
+.TP
+.BR MADV_FREE " (since Linux 3.19)"
+Tell the kernel that contents in the specified address range are no
+longer important and the range will be overwritten. When there is
+demand for memory, the system will free pages associated with the
+specified address range. In this instance, the next time a page in the
+address range is referenced, it will contain all zeroes.  Otherwise,

Quoted 8 lines

man2/madvise.2 file (see · line 282

Quoted 8 lines

man2/madvise.2 +5 -0

+it will contain the data that was there prior to the MADV_FREE call.
+References made to the address range will not make the system read
+from backing store (swap space) until the page is modified again.
+It works only with private anonymous pages (see
+.BR mmap (2)).
 .SH RETURN VALUE
 On success
 .BR madvise ()

If I'm reading the conversation right, the initially proposed text was from the BSD man page (which would be okay), but most of the text above seems to have come straight from the page here:
http://www.lehman.cuny.edu/cgi-bin/man-cgi?madvise+3

Quoted 1 line

Right?

True. Solaris man page was really straightforward/clear rather than BSD.

Quoted 5 lines

Unfortunately, I don't think we can use that text. It's from the Solaris man page as far as I can tell, and I doubt that it's under a license that we can use.

Quoted 7 lines

If that's the case, we need to go back and come up with an original text. It might draw inspiration from the Solaris page, and take actual text from the BSD page (which is under a free license), and it might also draw inspiration from Jon Corbet's description at http://lwn.net/Articles/590991/.

Could you take another shot this please!

No problem. I will test my essay writing skill.
Thanks.

Quoted 11 lines

Thanks,

Michael

Signature · 3 lines

Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

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>

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

Quoted 7 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Quoted 9 lines · Minchan Kim

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

Quoted 6 lines

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Yes, I'd like to check the symptom in memory pressure, so choose such test.

Quoted 5 lines

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

right.

Quoted 7 lines

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap is enabled. Our production environment doesn't enable swap, so I tried to delete the 'no swap' check and make MADV_FREE always enabled regardless if swap is enabled. I didn't change anything else. With such change, I saw oom immediately. So definitely we have aging issue, the pages aren't reclaimed fast.

Quoted 20 lines

Quoted 8 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

Quoted 9 lines

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Yes, they are definitely cold pages. I thought We should make sure the MADV_FREE pages are reclaimed first before other pages, at least in the anon LRU list, though there might be difficult to determine if we should reclaim writeback pages first or MADV_FREE pages first.

Thanks,
Shaohua

Quoted 34 lines · Shaohua Li

Quoted 9 lines · Minchan Kim

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

Quoted 6 lines

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Yes, I'd like to check the symptom in memory pressure, so choose such test.

Quoted 5 lines

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

right.

Quoted 7 lines

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

Quoted 6 lines

In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap is enabled. Our production environment doesn't enable swap, so I tried to delete the 'no swap' check and make MADV_FREE always enabled regardless if swap is enabled. I didn't change anything else. With such change, I saw oom immediately. So definitely we have aging issue, the pages aren't reclaimed fast.

In current VM implementation, it doesn't age anonymous LRU list if we have no swap. That's the reason to drop freeing pages instantly.
I think it could be enhanced later.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311591.html

Quoted 30 lines

Quoted 20 lines

Quoted 8 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

Quoted 9 lines

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Quoted 4 lines

Yes, they are definitely cold pages. I thought We should make sure the MADV_FREE pages are reclaimed first before other pages, at least in the anon LRU list, though there might be difficult to determine if we should reclaim writeback pages first or MADV_FREE pages first.

Frankly speaking, the issue with writeback page is just hurdle of implementation, not design so if we could fix it, we might move cold pages into tail of the inactive LRU. I tried it but don't have time slot to continue these days. Hope to get a time to look soon.
https://lkml.org/lkml/2014/7/1/628
Even, it wouldn't be critical problem although we couldn't fix the problem of writeback pages because they are already all cold pages so it might be not important to keep order in LRU so we could save working set and effort of VM to reclaim them at the cost of moving all of hinting pages into tail of the LRU whenever the syscall is called.

However, significant problem from my mind is we couldn't make sure they are really cold pages. It would be true for allocators but it's cache-friendly pages so it might be better to discard tail pages of inactive LRU, which are really cold.
In addition, we couldn't expect all of usecase for MADV_FREE so some of users might want to treat them as warm, not cold.

With moving them into inactive list's head, if we still see a lot stall, I think it's a sign to add other logic, for example, we could drop MADV_FREEed pages instantly if the zone is below low min watermark when the syscall is called. Because everybody doesn't like direct reclaim.

Quoted 101 lines · Minchan Kim

Quoted 34 lines · Shaohua Li

Quoted 9 lines · Minchan Kim

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

Quoted 6 lines

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Yes, I'd like to check the symptom in memory pressure, so choose such test.

Quoted 5 lines

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

right.

Quoted 7 lines

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

Quoted 6 lines

In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap is enabled. Our production environment doesn't enable swap, so I tried to delete the 'no swap' check and make MADV_FREE always enabled regardless if swap is enabled. I didn't change anything else. With such change, I saw oom immediately. So definitely we have aging issue, the pages aren't reclaimed fast.

In current VM implementation, it doesn't age anonymous LRU list if we have no swap. That's the reason to drop freeing pages instantly.
I think it could be enhanced later.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311591.html

Quoted 30 lines

Quoted 20 lines

Quoted 8 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

Quoted 9 lines

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Quoted 4 lines

Yes, they are definitely cold pages. I thought We should make sure the MADV_FREE pages are reclaimed first before other pages, at least in the anon LRU list, though there might be difficult to determine if we should reclaim writeback pages first or MADV_FREE pages first.

Frankly speaking, the issue with writeback page is just hurdle of implementation, not design so if we could fix it, we might move cold pages into tail of the inactive LRU. I tried it but don't have time slot to continue these days. Hope to get a time to look soon.
https://lkml.org/lkml/2014/7/1/628
Even, it wouldn't be critical problem although we couldn't fix the problem of writeback pages because they are already all cold pages so it might be not important to keep order in LRU so we could save working set and effort of VM to reclaim them at the cost of moving all of hinting pages into tail of the LRU whenever the syscall is called.

However, significant problem from my mind is we couldn't make sure they are really cold pages. It would be true for allocators but it's cache-friendly pages so it might be better to discard tail pages of inactive LRU, which are really cold.
In addition, we couldn't expect all of usecase for MADV_FREE so some of users might want to treat them as warm, not cold.

Quoted 5 lines

With moving them into inactive list's head, if we still see a lot stall, I think it's a sign to add other logic, for example, we could drop MADV_FREEed pages instantly if the zone is below low min watermark when the syscall is called. Because everybody doesn't like direct reclaim.

So I tried move the MADV_FREE pages to inactive list head or tail. It helps a little. But there are still stalls/oom. kswapd isn't fast enough to free the pages, App enters direct reclaim frequently. In one machine, no swap trigger, but MADV_FREE is 5x slower than MADV_DONTNEED. In another machine, MADV_FREE

trigers a lot of swap and sometimes even oom. app enters direct reclaim and has a lot of lock contention because of excessive direct reclaim, so there are a lot of stalls.

Thanks,
Shaohua

Hi Shaohua,

Quoted 108 lines · Shaohua Li

Quoted 101 lines · Minchan Kim

Quoted 34 lines · Shaohua Li

Quoted 9 lines · Minchan Kim

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

Quoted 6 lines

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Yes, I'd like to check the symptom in memory pressure, so choose such test.

Quoted 5 lines

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

right.

Quoted 7 lines

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

Quoted 6 lines

In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap is enabled. Our production environment doesn't enable swap, so I tried to delete the 'no swap' check and make MADV_FREE always enabled regardless if swap is enabled. I didn't change anything else. With such change, I saw oom immediately. So definitely we have aging issue, the pages aren't reclaimed fast.

In current VM implementation, it doesn't age anonymous LRU list if we have no swap. That's the reason to drop freeing pages instantly.
I think it could be enhanced later.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311591.html

Quoted 30 lines

Quoted 20 lines

Quoted 8 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

Quoted 9 lines

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Quoted 4 lines

Yes, they are definitely cold pages. I thought We should make sure the MADV_FREE pages are reclaimed first before other pages, at least in the anon LRU list, though there might be difficult to determine if we should reclaim writeback pages first or MADV_FREE pages first.

Frankly speaking, the issue with writeback page is just hurdle of implementation, not design so if we could fix it, we might move cold pages into tail of the inactive LRU. I tried it but don't have time slot to continue these days. Hope to get a time to look soon.
https://lkml.org/lkml/2014/7/1/628
Even, it wouldn't be critical problem although we couldn't fix the problem of writeback pages because they are already all cold pages so it might be not important to keep order in LRU so we could save working set and effort of VM to reclaim them at the cost of moving all of hinting pages into tail of the LRU whenever the syscall is called.

However, significant problem from my mind is we couldn't make sure they are really cold pages. It would be true for allocators but it's cache-friendly pages so it might be better to discard tail pages of inactive LRU, which are really cold.
In addition, we couldn't expect all of usecase for MADV_FREE so some of users might want to treat them as warm, not cold.

Quoted 5 lines

With moving them into inactive list's head, if we still see a lot stall, I think it's a sign to add other logic, for example, we could drop MADV_FREEed pages instantly if the zone is below low min watermark when the syscall is called. Because everybody doesn't like direct reclaim.

Quoted 4 lines

So I tried move the MADV_FREE pages to inactive list head or tail. It helps a little. But there are still stalls/oom. kswapd isn't fast enough to free the pages, App enters direct reclaim frequently. In one machine, no swap trigger, but MADV_FREE is 5x slower than MADV_DONTNEED. In another machine, MADV_FREE

It's expected. MADV_DONTNEED and MADV_FREE is really different. MADV_DONTNEED is self-sacrificy for others in the system while MADV_FREE is greedy approach for itself because random process asking the memory could enter direct reclaim.
However, as I said earlier, we could mitigate the problem by checking min_free_kbytes. If memory in the system is under min_free_kbytes, it is pointless to impose reclaim overhead for hinted pages because we alreay know the hint is "please free when you are trouble with memory" and we got know it already.

When I test below patch on my 3G machine + 12 CPU + 8G swap with below test
test: 12 processes(each process does 5 iteration: mmap 512M + memset + madvise),

1. MADV_DONTNEED : 41.884sec, sys:3m4.552
2. MADV_FREE : 1m28sec, sys: 5m23
3. MADV_FREE + below patch : 37.188s, sys: 2m20

Could you test?

mm/madvise.c +0 -0

index 6d0fcb8..da15f8f 100644

Quoted 135 lines · Minchan Kim

Hi Shaohua,

Quoted 108 lines · Shaohua Li

Quoted 101 lines · Minchan Kim

Quoted 34 lines · Shaohua Li

Quoted 9 lines · Minchan Kim

Hi Shaohua,

Quoted 5 lines · Shaohua Li

Hi Minchan,

Sorry to jump in this thread so later, and if some issues are discussed before. I'm interesting in this patch, so tried it here. I use a simple test with

Quoted 6 lines

No problem at all. Interest is always win over ignorance.

Quoted 2 lines

jemalloc. Obviously this can improve performance when there is no memory pressure. Did you try setup with memory pressure?

Sure but it was not a huge memory system like yours.

Yes, I'd like to check the symptom in memory pressure, so choose such test.

Quoted 5 lines

Quoted 3 lines

In my test, jemalloc will map 61G vma, and use about 32G memory without MADV_FREE. If MADV_FREE is enabled, jemalloc will use whole 61G memory because madvise doesn't reclaim the unused memory. If I disable swap (tweak your patch

Yes, IIUC, jemalloc replaces MADV_DONTNEED with MADV_FREE completely.

right.

Quoted 7 lines

Quoted 1 line

slightly to make it work without swap), I got oom. If swap is enabled, my

You mean you modified anon aging logic so it works although there is no swap? If so, I have no idea why OOM happens. I guess it should free all of freeable pages during the aging so although system stall happens more, I don't expect OOM. Anyway, with MADV_FREE with no swap, we should consider more things about anonymous aging.

Quoted 6 lines

In the patch, MADV_FREE will be disabled and fallback to DONTNEED if no swap is enabled. Our production environment doesn't enable swap, so I tried to delete the 'no swap' check and make MADV_FREE always enabled regardless if swap is enabled. I didn't change anything else. With such change, I saw oom immediately. So definitely we have aging issue, the pages aren't reclaimed fast.

In current VM implementation, it doesn't age anonymous LRU list if we have no swap. That's the reason to drop freeing pages instantly.
I think it could be enhanced later.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311591.html

Quoted 30 lines

Quoted 20 lines

Quoted 8 lines

system is totally stalled because of swap activity. Without the MADV_FREE, everything is ok. Considering we definitely don't want to waste too much memory, a system with memory pressure is normal, so sounds MADV_FREE will introduce big trouble here.

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

I think it's desirable if the page lived in active LRU.
The reason I didn't that was caused by volatile ranges system call which was motivaion for MADV_FREE in my mind.
In last LSF/MM, there was concern about data's hotness.
Some of users want to keep that as it is in LRU position, others want to handle that as cold(tail of inactive list)/warm(head of inactive list)/ hot(head of active list), for example.
The vrange syscall was just about volatiltiy, not depends on page hotness so the decision on my head was not to change LRU order and let's make new hotness advise if we need it later.

Quoted 9 lines

However, MADV_FREE's main customer is allocators and afaik, they want to replace MADV_DONTNEED with MADV_FREE so I think it is really cold, but we couldn't make sure so head of inactive is good compromise. Another concern about tail of inactive list is that there could be plenty of pages in there, which was asynchromos write-backed in previous reclaim path, not-yet reclaimed because of not being able to free the in softirq context of writeback. It means we ends up freeing more potential pages to become workingset in advance than pages VM already decided to evict.

Quoted 4 lines

Yes, they are definitely cold pages. I thought We should make sure the MADV_FREE pages are reclaimed first before other pages, at least in the anon LRU list, though there might be difficult to determine if we should reclaim writeback pages first or MADV_FREE pages first.

Frankly speaking, the issue with writeback page is just hurdle of implementation, not design so if we could fix it, we might move cold pages into tail of the inactive LRU. I tried it but don't have time slot to continue these days. Hope to get a time to look soon.
https://lkml.org/lkml/2014/7/1/628
Even, it wouldn't be critical problem although we couldn't fix the problem of writeback pages because they are already all cold pages so it might be not important to keep order in LRU so we could save working set and effort of VM to reclaim them at the cost of moving all of hinting pages into tail of the LRU whenever the syscall is called.

However, significant problem from my mind is we couldn't make sure they are really cold pages. It would be true for allocators but it's cache-friendly pages so it might be better to discard tail pages of inactive LRU, which are really cold.
In addition, we couldn't expect all of usecase for MADV_FREE so some of users might want to treat them as warm, not cold.

Quoted 5 lines

With moving them into inactive list's head, if we still see a lot stall, I think it's a sign to add other logic, for example, we could drop MADV_FREEed pages instantly if the zone is below low min watermark when the syscall is called. Because everybody doesn't like direct reclaim.

Quoted 4 lines

So I tried move the MADV_FREE pages to inactive list head or tail. It helps a little. But there are still stalls/oom. kswapd isn't fast enough to free the pages, App enters direct reclaim frequently. In one machine, no swap trigger, but MADV_FREE is 5x slower than MADV_DONTNEED. In another machine, MADV_FREE

It's expected. MADV_DONTNEED and MADV_FREE is really different. MADV_DONTNEED is self-sacrificy for others in the system while MADV_FREE is greedy approach for itself because random process asking the memory could enter direct reclaim.
However, as I said earlier, we could mitigate the problem by checking min_free_kbytes. If memory in the system is under min_free_kbytes, it is pointless to impose reclaim overhead for hinted pages because we alreay know the hint is "please free when you are trouble with memory" and we got know it already.

When I test below patch on my 3G machine + 12 CPU + 8G swap with below test
test: 12 processes(each process does 5 iteration: mmap 512M + memset + madvise),

1. MADV_DONTNEED : 41.884sec, sys:3m4.552
2. MADV_FREE : 1m28sec, sys: 5m23
3. MADV_FREE + below patch : 37.188s, sys: 2m20

Could you test?

mm/madvise.c madvise_vma(struct vm_area_struct *vma, struct vm_area_struct **prev, · line 529

Quoted 13 lines

mm/madvise.c +1 -1

index 6d0fcb8..da15f8f 100644
@@ -523,7 +523,7 @@ madvise_vma(struct vm_area_struct *vma, struct vm_area_struct **prev,
 		 * XXX: In this implementation, MADV_FREE works like
 		 * MADV_DONTNEED on swapless system or full swap.
 		 */
-		if (get_nr_swap_pages() > 0)
+		if (get_nr_swap_pages() > 0 && min_free_kbytes < nr_free_pages())
 			return madvise_free(vma, prev, start, end);
 		/* passthrough */
 	case MADV_DONTNEED:

The throttling makes a lot of sense, definitely should be included in the patch. At least my jemalloc test has similar performance result with/without

the patch in memory pressure case. So overall I'm pretty happy with it.

However, this only solves half of the problem. pages which are MADV_FREE before watermark is hit are still hard to be reclaimed later if there are other allocations. I'm not sure how severe this issue is. My jemalloc test frequently does madvise (fallback to DONTNEED with above change), so itself can free a lot of memory in memory pressure. If application uses MADV_FREE before watermark is hit, but don't use it after watermark is hit, we will have trouble.

Thanks,
Shaohua

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

On Thu 05-02-15 16:33:11, Shaohua Li wrote:
[...]

Quoted 2 lines

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

Yes this makes sense for pages living on the active LRU list. I would preserve LRU ordering on the inactive list because there is no good reason to make the operation more costly for inactive pages. On the other hand having tons of to-be-freed pages on the active list clearly sucks. Care to send a patch?

Quoted 9 lines · Michal Hocko

On Thu 05-02-15 16:33:11, Shaohua Li wrote: [...]

Quoted 2 lines

Did you think about move the MADV_FREE pages to the head of inactive LRU, so they can be reclaimed easily?

Yes this makes sense for pages living on the active LRU list. I would preserve LRU ordering on the inactive list because there is no good reason to make the operation more costly for inactive pages. On the other hand having tons of to-be-freed pages on the active list clearly sucks. Care to send a patch?

Considering anon pages are in active LRU first, it's likely MADV_FREE pages are in active list. I'm curious why preserves the order of inactive list.

If I'm reading the conversation right, the initially proposed text was from the BSD man page (which would be okay), but most of the text above seems to have come straight from the page here:
http://www.lehman.cuny.edu/cgi-bin/man-cgi?madvise+3

Right?

Unfortunately, I don't think we can use that text. It's from the Solaris man page as far as I can tell, and I doubt that it's under a license that we can use.

If that's the case, we need to go back and come up with an original text. It might draw inspiration from the Solaris page, and take actual text from the BSD page (which is under a free license), and it might also draw inspiration from Jon Corbet's description at http://lwn.net/Articles/590991/.

Could you take another shot this please!

We don't need to split THP page when MADV_FREE syscall is called. It could be done when VM decide really frees it so we could avoid unnecessary THP split.

Cc Andrea Arcangeli <[email protected]>

Acked-by Rik van Riel <[email protected]>

Acked-by Kirill A. Shutemov <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

---
 include/linux/huge_mm.h |  4 ++++
 mm/huge_memory.c        | 35 +++++++++++++++++++++++++++++++++++
 mm/madvise.c            | 21 ++++++++++++++++++++-
 mm/rmap.c               |  8 ++++++--
 mm/vmscan.c             | 28 ++++++++++++++++++----------
 5 files changed, 83 insertions(+), 13 deletions(-)

mm/madvise.c +4 -0

index a21584235bb6..84badee5f46d 100644
@@ -271,8 +271,26 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	spinlock_t *ptl;
 	pte_t *pte, ptent;
 	struct page *page;
+	unsigned long next;
+
+	next = pmd_addr_end(addr, end);
+	if (pmd_trans_huge(*pmd)) {

mm/madvise.c +6 -1

+			split_huge_page_pmd(vma, addr, pmd);
+		} else if (!madvise_free_huge_pmd(tlb, vma, pmd, addr))
+			goto next;
+		/* fall through */
+	}
 
-	split_huge_page_pmd(vma, addr, pmd);
 	if (pmd_trans_unstable(pmd))
 		return 0;
 

@@ -316,6 +334,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	}
 	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(pte - 1, ptl);
+next:
 	cond_resched();
 	return 0;
 }

Quoted 4 lines · Minchan Kim

We don't need to split THP page when MADV_FREE syscall is called. It could be done when VM decide really frees it so we could avoid unnecessary THP split.

Quoted 4 lines

Cc Andrea Arcangeli <[email protected]>

Acked-by Rik van Riel <[email protected]>

Acked-by Kirill A. Shutemov <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

Other than a minor comment below

Reviewed-by Michal Hocko <[email protected]>

Quoted 9 lines

---
 include/linux/huge_mm.h |  4 ++++
 mm/huge_memory.c        | 35 +++++++++++++++++++++++++++++++++++
 mm/madvise.c            | 21 ++++++++++++++++++++-
 mm/rmap.c               |  8 ++++++--
 mm/vmscan.c             | 28 ++++++++++++++++++----------
 5 files changed, 83 insertions(+), 13 deletions(-)

[...]

Quoted 18 lines

mm/madvise.c +10 -0

index a21584235bb6..84badee5f46d 100644
@@ -271,8 +271,26 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	spinlock_t *ptl;
 	pte_t *pte, ptent;
 	struct page *page;
+	unsigned long next;
+
+	next = pmd_addr_end(addr, end);
+	if (pmd_trans_huge(*pmd)) {
+		if (next - addr != HPAGE_PMD_SIZE) {
+#ifdef CONFIG_DEBUG_VM
+			if (!rwsem_is_locked(&mm->mmap_sem)) {
+				pr_err("%s: mmap_sem is unlocked! addr=0x%lx end=0x%lx vma->vm_start=0x%lx vma->vm_end=0x%lx\n",
+					__func__, addr, end,
+					vma->vm_start,

mm/madvise.c static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, · line 287

Quoted 4 lines

mm/madvise.c +4 -0

+					vma->vm_end);
+				BUG();
+			}
+#endif

Why is this code here? madvise_free_pte_range is called only from the madvise path and we are holding mmap_sem and relying on that for regular pages as well.

This patch enable MADV_FREE hint for madvise syscall, which have been supported by other OSes. [PATCH 1] includes the details.

[1] support MADVISE_FREE for !THP page so if VM encounter THP page in syscall context, it splits THP page.
[2-6] is to preparing to call madvise syscall without THP plitting
[7] enable THP page support for MADV_FREE.

* from v16
* Rebased on mmotm-2014-10-15-16-57

* from v15
* Add more Acked-by - Rik van Riel
* Rebased on mmotom-08-29-15-15

* from v14
* Add more Ackedy-by from arch people(sparc, arm64 and arm)
* Drop s390 since pmd_dirty/clean was merged

* from v13
* Add more Ackedy-by from arch people(arm, arm64 and ppc)
* Rebased on mmotm 2014-08-13-14-29

* from v12
* Fix - skip to mark free pte on try_to_free_swap failed page - Kirill
* Add more Acked-by from arch maintainers and Kirill

* From v11
* Fix arm build - Steve
* Separate patch for arm and arm64 - Steve
* Remove unnecessary check - Kirill
* Skip non-vm_normal page - Kirill
* Add Acked-by - Zhang
* Sparc64 build fix
* Pagetable walker THP handling fix

* From v10
* Add Acked-by from arch stuff(x86, s390)
* Pagewalker based pagetable working - Kirill
* Fix try_to_unmap_one broken with hwpoison - Kirill
* Use VM_BUG_ON_PAGE in madvise_free_pmd - Kirill
* Fix pgtable-3level.h for arm - Steve

* From v9
* Add Acked-by - Rik
* Add THP page support - Kirill

* From v8
* Rebased-on v3.16-rc2-mmotm-2014-06-25-16-44

* From v7
* Rebased-on next-20140613

* From v6
* Remove page from swapcache in syscal time
* Move utility functions from memory.c to madvise.c - Johannes
* Rename untilify functtions - Johannes
* Remove unnecessary checks from vmscan.c - Johannes
* Rebased-on v3.15-rc5-mmotm-2014-05-16-16-56
* Drop Reviewe-by because there was some changes since then.

* From v5
* Fix PPC problem which don't flush TLB - Rik
* Remove unnecessary lazyfree_range stub function - Rik
* Rebased on v3.15-rc5

* From v4
* Add Reviewed-by: Zhang Yanfei
* Rebase on v3.15-rc1-mmotm-2014-04-15-16-14

* From v3
* Add "how to work part" in description - Zhang
* Add page_discardable utility function - Zhang
* Clean up

* From v2
* Remove forceful dirty marking of swap-readed page - Johannes
* Remove deactivation logic of lazyfreed page
* Rebased on 3.14
* Remove RFC tag

* From v1
* Use custom page table walker for madvise_free - Johannes
* Remove PG_lazypage flag - Johannes
* Do madvise_dontneed instead of madvise_freein swapless system

Minchan Kim (7):
mm: support madvise(MADV_FREE)
x86: add pmd_[dirty|mkclean] for THP
sparc: add pmd_[dirty|mkclean] for THP
powerpc: add pmd_[dirty|mkclean] for THP
arm: add pmd_mkclean for THP
arm64: add pmd_[dirty|mkclean] for THP
mm: Don't split THP page when syscall is called

 arch/arm/include/asm/pgtable-3level.h    |   1 +
 arch/arm64/include/asm/pgtable.h         |   2 +
 arch/powerpc/include/asm/pgtable-ppc64.h |   2 +
 arch/sparc/include/asm/pgtable_64.h      |  16 ++++
 arch/x86/include/asm/pgtable.h           |  10 ++
 include/linux/huge_mm.h                  |   4 +
 include/linux/rmap.h                     |   9 +-
 include/linux/vm_event_item.h            |   1 +
 include/uapi/asm-generic/mman-common.h   |   1 +
 mm/huge_memory.c                         |  35 +++++++
 mm/madvise.c                             | 159 +++++++++++++++++++++++++++++++
 mm/rmap.c                                |  46 ++++++++-
 mm/vmscan.c                              |  64 +++++++++----
 mm/vmstat.c                              |   1 +
 14 files changed, 331 insertions(+), 20 deletions(-)

Signature · 7 lines

2.0.0

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

It seems I have waited your review for a long time. What should I do to take your time slot?