On Thu, Jan 28, 2016 at 08:16:25AM +0100, Michael Kerrisk (man-pages) wrote:
Hello Minchan,
On 11/30/2015 07:39 AM, Minchan Kim wrote:
quoted
In v4, Andrew wanted to settle in old basic MADV_FREE and introduces
new stuffs(ie, lazyfree LRU, swapless support and lazyfreeness) later
so this version doesn't include them.
I have been tested it on mmotm-2015-11-25-17-08 with additional
patch[1] from Kirill to prevent BUG_ON which he didn't send to
linux-mm yet as formal patch. With it, I couldn't find any
problem so far.
Note that this version is based on THP refcount redesign so
I needed some modification on MADV_FREE because split_huge_pmd
doesn't split a THP page any more and pmd_trans_huge(pmd) is not
enough to guarantee the page is not THP page.
As well, for MAVD_FREE lazy-split, THP split should respect
pmd's dirtiness rather than marking ptes of all subpages dirty
unconditionally. Please, review last patch in this patchset.
Now that MADV_FREE has been merged, would you be willing to write
patch to the madvise(2) man page that describes the semantics,
noes limitations and restrictions, and (ideally) has some sentences
describing use cases?
Hello Michael,
Could you review this patch?
Thanks.
From 203372f901f574e991215fdff6907608ba53f932 Mon Sep 17 00:00:00 2001
From: Minchan Kim <redacted>
Date: Fri, 5 Feb 2016 11:09:54 +0900
Subject: [PATCH] madvise.2: Add MADV_FREE
Document the MADV_FREE flags added to madvise() in Linux 4.5
Signed-off-by: Minchan Kim <redacted>
---
man2/madvise.2 | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/man2/madvise.2 b/man2/madvise.2
index c1df67c..4704304 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -143,6 +143,25 @@ flag are special memory areas that are not managed
by the virtual memory subsystem.
Such pages are typically created by device drivers that
map the pages into user space.)
+.TP
+.B MADV_FREE " (since Linux 4.5)"
+Application is finished with the given range, so kernel can free
+resources associated with it but the freeing could be delayed until
+memory pressure happens or canceld by write operation by user.
+
+After a successful MADV_FREE operation, user shouldn't expect kernel
+keeps stale data on the page. However, subsequent write of pages
+in the range will succeed and then kernel cannot free those dirtied pages
+so user can always see just written data. If there was no subsequent
+write, kernel can free those clean pages any time. In such case,
+user can see zero-fill-on-demand pages.
+
+Note that, it works only with private anonymous pages (see
+.BR mmap (2)).
+On swapless system, freeing pages in given range happens instantly
+regardless of memory pressure.
+
+
.\"
.\" ======================================================================
.\"
--
1.9.1
Hello Minchan,
On 02/05/2016 03:15 AM, Minchan Kim wrote:
quoted hunk
On Thu, Jan 28, 2016 at 08:16:25AM +0100, Michael Kerrisk (man-pages) wrote:
quoted
Hello Minchan,
On 11/30/2015 07:39 AM, Minchan Kim wrote:
quoted
In v4, Andrew wanted to settle in old basic MADV_FREE and introduces
new stuffs(ie, lazyfree LRU, swapless support and lazyfreeness) later
so this version doesn't include them.
I have been tested it on mmotm-2015-11-25-17-08 with additional
patch[1] from Kirill to prevent BUG_ON which he didn't send to
linux-mm yet as formal patch. With it, I couldn't find any
problem so far.
Note that this version is based on THP refcount redesign so
I needed some modification on MADV_FREE because split_huge_pmd
doesn't split a THP page any more and pmd_trans_huge(pmd) is not
enough to guarantee the page is not THP page.
As well, for MAVD_FREE lazy-split, THP split should respect
pmd's dirtiness rather than marking ptes of all subpages dirty
unconditionally. Please, review last patch in this patchset.
Now that MADV_FREE has been merged, would you be willing to write
patch to the madvise(2) man page that describes the semantics,
noes limitations and restrictions, and (ideally) has some sentences
describing use cases?
Hello Michael,
Could you review this patch?
Thanks.
quoted
From 203372f901f574e991215fdff6907608ba53f932 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Fri, 5 Feb 2016 11:09:54 +0900
Subject: [PATCH] madvise.2: Add MADV_FREE
Document the MADV_FREE flags added to madvise() in Linux 4.5
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
man2/madvise.2 | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/man2/madvise.2 b/man2/madvise.2
index c1df67c..4704304 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -143,6 +143,25 @@ flag are special memory areas that are not managed
by the virtual memory subsystem.
Such pages are typically created by device drivers that
map the pages into user space.)
+.TP
+.B MADV_FREE " (since Linux 4.5)"
+Application is finished with the given range, so kernel can free
+resources associated with it but the freeing could be delayed until
+memory pressure happens or canceld by write operation by user.
+
+After a successful MADV_FREE operation, user shouldn't expect kernel
+keeps stale data on the page. However, subsequent write of pages
+in the range will succeed and then kernel cannot free those dirtied pages
+so user can always see just written data. If there was no subsequent
+write, kernel can free those clean pages any time. In such case,
+user can see zero-fill-on-demand pages.
+
+Note that, it works only with private anonymous pages (see
+.BR mmap (2)).
+On swapless system, freeing pages in given range happens instantly
+regardless of memory pressure.
+
+
.\"
.\" ======================================================================
.\"
Thanks for the nice text! I reworked somewhat, trying to fill out a
few details about how I understand things work, but I may have introduced
errors, so I would be happy if you would check the following text:
MADV_FREE (since Linux 4.5)
The application no longer requires the pages in the
range specified by addr and len. The kernel can thus
free these pages, but the freeing could be delayed until
memory pressure occurs. For each of the pages that has
been marked to be freed but has not yet been freed, the
free operation will be canceled if the caller writes
into the page. After a successful MADV_FREE operation,
any stale data (i.e., dirty, unwritten pages) will be
lost when the kernel frees the pages. However, subse‐
quent writes to pages in the range will succeed and then
kernel cannot free those dirtied pages, so that the
caller can always see just written data. If there is no
subsequent write, the kernel can free the pages at any
time. Once pages in the range have been freed, the
caller will see zero-fill-on-demand pages upon subse‐
quent page references.
The MADV_FREE operation can be applied only to private
anonymous pages (see mmap(2)). On a swapless system,
freeing pages in a given range happens instantly,
regardless of memory pressure.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
On Sat, Feb 06, 2016 at 02:32:02PM +0100, Michael Kerrisk (man-pages) wrote:
Hello Minchan,
On 02/05/2016 03:15 AM, Minchan Kim wrote:
quoted
On Thu, Jan 28, 2016 at 08:16:25AM +0100, Michael Kerrisk (man-pages) wrote:
quoted
Hello Minchan,
On 11/30/2015 07:39 AM, Minchan Kim wrote:
quoted
In v4, Andrew wanted to settle in old basic MADV_FREE and introduces
new stuffs(ie, lazyfree LRU, swapless support and lazyfreeness) later
so this version doesn't include them.
I have been tested it on mmotm-2015-11-25-17-08 with additional
patch[1] from Kirill to prevent BUG_ON which he didn't send to
linux-mm yet as formal patch. With it, I couldn't find any
problem so far.
Note that this version is based on THP refcount redesign so
I needed some modification on MADV_FREE because split_huge_pmd
doesn't split a THP page any more and pmd_trans_huge(pmd) is not
enough to guarantee the page is not THP page.
As well, for MAVD_FREE lazy-split, THP split should respect
pmd's dirtiness rather than marking ptes of all subpages dirty
unconditionally. Please, review last patch in this patchset.
Now that MADV_FREE has been merged, would you be willing to write
patch to the madvise(2) man page that describes the semantics,
noes limitations and restrictions, and (ideally) has some sentences
describing use cases?
Hello Michael,
Could you review this patch?
Thanks.
quoted
From 203372f901f574e991215fdff6907608ba53f932 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Fri, 5 Feb 2016 11:09:54 +0900
Subject: [PATCH] madvise.2: Add MADV_FREE
Document the MADV_FREE flags added to madvise() in Linux 4.5
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
man2/madvise.2 | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/man2/madvise.2 b/man2/madvise.2
index c1df67c..4704304 100644
--- a/man2/madvise.2
+++ b/man2/madvise.2
@@ -143,6 +143,25 @@ flag are special memory areas that are not managed
by the virtual memory subsystem.
Such pages are typically created by device drivers that
map the pages into user space.)
+.TP
+.B MADV_FREE " (since Linux 4.5)"
+Application is finished with the given range, so kernel can free
+resources associated with it but the freeing could be delayed until
+memory pressure happens or canceld by write operation by user.
+
+After a successful MADV_FREE operation, user shouldn't expect kernel
+keeps stale data on the page. However, subsequent write of pages
+in the range will succeed and then kernel cannot free those dirtied pages
+so user can always see just written data. If there was no subsequent
+write, kernel can free those clean pages any time. In such case,
+user can see zero-fill-on-demand pages.
+
+Note that, it works only with private anonymous pages (see
+.BR mmap (2)).
+On swapless system, freeing pages in given range happens instantly
+regardless of memory pressure.
+
+
.\"
.\" ======================================================================
.\"
Thanks for the nice text! I reworked somewhat, trying to fill out a
few details about how I understand things work, but I may have introduced
errors, so I would be happy if you would check the following text:
Below looks good to me.
Thanks, Michael
MADV_FREE (since Linux 4.5)
The application no longer requires the pages in the
range specified by addr and len. The kernel can thus
free these pages, but the freeing could be delayed until
memory pressure occurs. For each of the pages that has
been marked to be freed but has not yet been freed, the
free operation will be canceled if the caller writes
into the page. After a successful MADV_FREE operation,
any stale data (i.e., dirty, unwritten pages) will be
lost when the kernel frees the pages. However, subse‐
quent writes to pages in the range will succeed and then
kernel cannot free those dirtied pages, so that the
caller can always see just written data. If there is no
subsequent write, the kernel can free the pages at any
time. Once pages in the range have been freed, the
caller will see zero-fill-on-demand pages upon subse‐
quent page references.
The MADV_FREE operation can be applied only to private
anonymous pages (see mmap(2)). On a swapless system,
freeing pages in a given range happens instantly,
regardless of memory pressure.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>