Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1259262 > unrolled thread

[PATCH 0/8] MADV_FREE support

Started byMinchan Kim <minchan@kernel.org>
First post2015-10-30 08:10 +0100
Last post2015-11-04 21:20 +0100
Articles 20 on this page of 21 — 7 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/8] MADV_FREE support Minchan Kim <minchan@kernel.org> - 2015-10-30 08:10 +0100
    [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures Minchan Kim <minchan@kernel.org> - 2015-10-30 08:10 +0100
      Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same  value for all architectures Hugh Dickins <hughd@google.com> - 2015-11-02 01:10 +0100
        Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same  value for all architectures Minchan Kim <minchan@kernel.org> - 2015-11-03 03:40 +0100
          Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same  value for all architectures David Miller <davem@davemloft.net> - 2015-11-03 04:40 +0100
            Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same  value for all architectures Minchan Kim <minchan@kernel.org> - 2015-11-03 05:40 +0100
        Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same  value for all architectures Minchan Kim <minchan@kernel.org> - 2015-11-03 03:40 +0100
    [PATCH 1/8] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-10-30 08:10 +0100
      Re: [PATCH 1/8] mm: support madvise(MADV_FREE) Shaohua Li <shli@kernel.org> - 2015-10-30 17:50 +0100
        Re: [PATCH 1/8] mm: support madvise(MADV_FREE) Minchan Kim <minchan@kernel.org> - 2015-11-03 01:20 +0100
    [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced Minchan Kim <minchan@kernel.org> - 2015-10-30 08:10 +0100
      Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced Michal Hocko <mhocko@kernel.org> - 2015-10-30 13:50 +0100
        Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced Minchan Kim <minchan@kernel.org> - 2015-11-03 02:20 +0100
          Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced Michal Hocko <mhocko@kernel.org> - 2015-11-04 09:30 +0100
    [PATCH 4/8] mm: free swp_entry in madvise_free Minchan Kim <minchan@kernel.org> - 2015-10-30 08:10 +0100
      Re: [PATCH 4/8] mm: free swp_entry in madvise_free Michal Hocko <mhocko@kernel.org> - 2015-10-30 13:30 +0100
        Re: [PATCH 4/8] mm: free swp_entry in madvise_free Minchan Kim <minchan@kernel.org> - 2015-11-03 02:00 +0100
    Re: [PATCH 0/8] MADV_FREE support David Rientjes <rientjes@google.com> - 2015-11-01 06:00 +0100
      Re: [PATCH 0/8] MADV_FREE support Daniel Micay <danielmicay@gmail.com> - 2015-11-01 07:40 +0100
        Re: [PATCH 0/8] MADV_FREE support Minchan Kim <minchan@kernel.org> - 2015-11-03 03:30 +0100
        Re: [PATCH 0/8] MADV_FREE support David Rientjes <rientjes@google.com> - 2015-11-04 21:20 +0100

Page 1 of 2  [1] 2  Next page →


#1259262 — [PATCH 0/8] MADV_FREE support

FromMinchan Kim <minchan@kernel.org>
Date2015-10-30 08:10 +0100
Subject[PATCH 0/8] MADV_FREE support
Message-ID<qpbYZ-2NI-5@gated-at.bofh.it>
MADV_FREE is on linux-next so long time. The reason was two, I think.

1. MADV_FREE code on reclaim path was really mess.

2. Andrew really want to see voice of userland people who want to use
   the syscall.

A few month ago, Daniel Micay(jemalloc active contributor) requested me
to make progress upstreaming but I was busy at that time so it took
so long time for me to revist the code and finally, I clean it up the
mess recently so it solves the #2 issue.

As well, Daniel and Jason(jemalloc maintainer) requested it to Andrew
again recently and they said it would be great to have even though
it has swap dependency now so Andrew decided he will do that for v4.4.

When I test MADV_FREE patches on recent mmotm, there is some
problem with THP-refcount redesign so it's hard for long running
test. Even, there is some dependency with it because patch ordering of
MADV_FREE in mmotm is after THP refcount redesign so I discussed it
with Andrew in hallway this kernel summit and decided to send
patchset based on v4.3-rc7.

I have been tested it on v4.3-rc7 and couldn't find any problem so far.

In the meanwhile, Hugh reviewed all of code and asked me to tidy up
a lot patches related MADV_FREE on mmotm so this is the result of
the request.

In this version, I drop a enhance patch.

        mm: don't split THP page when syscall is called

Because it could delay split of THP page until reclaim path but it
made madvise_free void due to marking all pages(head + sub pages)
PG_dirty and pte_mkdirty when split happens.

I will see we could make THP split inheriting pmd's dirtiness to
subpages and remove adding PG_dirty part unconditionally in
__split_huge_page_refcount but it's rather risky to do it in
this moment(ie, close to merge window and Kirill is changing
that a lot) so I want to do it after closing merge window.
If we dont't do it now, we don't need following patches, either.

	x86-add-pmd_-for-thp.patch
	x86-add-pmd_-for-thp-fix.patch
	sparc-add-pmd_-for-thp.patch
	sparc-add-pmd_-for-thp-fix.patch
	powerpc-add-pmd_-for-thp.patch
	arm-add-pmd_mkclean-for-thp.patch
	arm64-add-pmd_-for-thp.patch

So, I drop those patch too in this version and will resend it
when I send a lazy split patch of THP page.

A final modification since I sent clean up patchset(ie, MADV_FREE
refactoring and fix KSM page), there are three.

 1. Replace description and comment of KSM fix patch with Hugh's suggestion
 2. Avoid forcing SetPageDirty in try_to_unmap_one to avoid clean
    page swapout from Yalin
 3. Adding uapi patch to make value of MADV_FREE for all arches same
    from Chen

About 3, I include it because I thought it was good but Andrew
just missed the patch at that time. But when I read quilt series
file now, it seems Shaohua had some problem with it but I couldn't
find any mail in my mailbox. If it has something wrong,
please tell us.

#mm-support-madvisemadv_free.patch: other-arch syscall numbering mess ("arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures"). Shaohua Li <shli@kernel.org> testing disasters.

TODO: I will send man page patch if it would land for v4.4.

Andrew, you could replace all of MADV_FREE related patches with
this. IOW, these are

	# MADV_FREE stuff:
	x86-add-pmd_-for-thp.patch
	x86-add-pmd_-for-thp-fix.patch
	sparc-add-pmd_-for-thp.patch
	sparc-add-pmd_-for-thp-fix.patch
	powerpc-add-pmd_-for-thp.patch
	arm-add-pmd_mkclean-for-thp.patch
	arm64-add-pmd_-for-thp.patch

	mm-support-madvisemadv_free.patch
	mm-support-madvisemadv_free-fix.patch
	mm-support-madvisemadv_free-fix-2.patch
	mm-support-madvisemadv_free-fix-3.patch
	mm-support-madvisemadv_free-vs-thp-rename-split_huge_page_pmd-to-split_huge_pmd.patch
	mm-support-madvisemadv_free-fix-5.patch
	mm-support-madvisemadv_free-fix-6.patch
	mm-mark-stable-page-dirty-in-ksm.patch
	mm-dont-split-thp-page-when-syscall-is-called.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-2.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-3.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-4.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-5.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-6.patch
	mm-dont-split-thp-page-when-syscall-is-called-fix-6-fix.patch
	mm-free-swp_entry-in-madvise_free.patch
	mm-move-lazy-free-pages-to-inactive-list.patch
	mm-move-lazy-free-pages-to-inactive-list-fix.patch
	mm-move-lazy-free-pages-to-inactive-list-fix-fix.patch
	mm-move-lazy-free-pages-to-inactive-list-fix-fix-fix.patch

Chen Gang (1):
  arch: uapi: asm: mman.h: Let MADV_FREE have same value for all
    architectures

Minchan Kim (7):
  mm: support madvise(MADV_FREE)
  mm: define MADV_FREE for some arches
  mm: free swp_entry in madvise_free
  mm: move lazily freed pages to inactive list
  mm: lru_deactivate_fn should clear PG_referenced
  mm: clear PG_dirty to mark page freeable
  mm: mark stable page dirty in KSM

 arch/alpha/include/uapi/asm/mman.h     |   1 +
 arch/mips/include/uapi/asm/mman.h      |   1 +
 arch/parisc/include/uapi/asm/mman.h    |   1 +
 arch/xtensa/include/uapi/asm/mman.h    |   1 +
 include/linux/rmap.h                   |   1 +
 include/linux/swap.h                   |   1 +
 include/linux/vm_event_item.h          |   1 +
 include/uapi/asm-generic/mman-common.h |   1 +
 mm/ksm.c                               |   6 ++
 mm/madvise.c                           | 162 +++++++++++++++++++++++++++++++++
 mm/rmap.c                              |   7 ++
 mm/swap.c                              |  44 +++++++++
 mm/swap_state.c                        |   5 +-
 mm/vmscan.c                            |  10 +-
 mm/vmstat.c                            |   1 +
 15 files changed, 238 insertions(+), 5 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1259263 — [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromMinchan Kim <minchan@kernel.org>
Date2015-10-30 08:10 +0100
Subject[PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qpbZ0-2NI-17@gated-at.bofh.it>
In reply to#1259262
From: Chen Gang <gang.chen.5i5j@gmail.com>

For uapi, need try to let all macros have same value, and MADV_FREE is
added into main branch recently, so need redefine MADV_FREE for it.

At present, '8' can be shared with all architectures, so redefine it to
'8'.

Cc: rth@twiddle.net <rth@twiddle.net>,
Cc: ink@jurassic.park.msu.ru <ink@jurassic.park.msu.ru>
Cc: mattst88@gmail.com <mattst88@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: jejb@parisc-linux.org <jejb@parisc-linux.org>
Cc: deller@gmx.de <deller@gmx.de>
Cc: chris@zankel.net <chris@zankel.net>
Cc: jcmvbkbc@gmail.com <jcmvbkbc@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Cc: linux-api@vger.kernel.org
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 arch/alpha/include/uapi/asm/mman.h     | 2 +-
 arch/mips/include/uapi/asm/mman.h      | 2 +-
 arch/parisc/include/uapi/asm/mman.h    | 2 +-
 arch/xtensa/include/uapi/asm/mman.h    | 2 +-
 include/uapi/asm-generic/mman-common.h | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
index 836fbd44f65b..0b8a5de7aee3 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -44,9 +44,9 @@
 #define MADV_WILLNEED	3		/* will need these pages */
 #define	MADV_SPACEAVAIL	5		/* ensure resources are available */
 #define MADV_DONTNEED	6		/* don't need these pages */
-#define MADV_FREE	7		/* free pages only if memory pressure */
 
 /* common/generic parameters */
+#define MADV_FREE	8		/* free pages only if memory pressure */
 #define MADV_REMOVE	9		/* remove these pages & resources */
 #define MADV_DONTFORK	10		/* don't inherit across fork */
 #define MADV_DOFORK	11		/* do inherit across fork */
diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h
index 106e741aa7ee..d247f5457944 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -67,9 +67,9 @@
 #define MADV_SEQUENTIAL 2		/* expect sequential page references */
 #define MADV_WILLNEED	3		/* will need these pages */
 #define MADV_DONTNEED	4		/* don't need these pages */
-#define MADV_FREE	5		/* free pages only if memory pressure */
 
 /* common parameters: try to keep these consistent across architectures */
+#define MADV_FREE	8		/* free pages only if memory pressure */
 #define MADV_REMOVE	9		/* remove these pages & resources */
 #define MADV_DONTFORK	10		/* don't inherit across fork */
 #define MADV_DOFORK	11		/* do inherit across fork */
diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h
index 6cb8db76fd4e..700d83fd9352 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -40,9 +40,9 @@
 #define MADV_SPACEAVAIL 5               /* insure that resources are reserved */
 #define MADV_VPS_PURGE  6               /* Purge pages from VM page cache */
 #define MADV_VPS_INHERIT 7              /* Inherit parents page size */
-#define MADV_FREE	8		/* free pages only if memory pressure */
 
 /* common/generic parameters */
+#define MADV_FREE	8		/* free pages only if memory pressure */
 #define MADV_REMOVE	9		/* remove these pages & resources */
 #define MADV_DONTFORK	10		/* don't inherit across fork */
 #define MADV_DOFORK	11		/* do inherit across fork */
diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
index 1b19f25bc567..77eaca434071 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -80,9 +80,9 @@
 #define MADV_SEQUENTIAL	2		/* expect sequential page references */
 #define MADV_WILLNEED	3		/* will need these pages */
 #define MADV_DONTNEED	4		/* don't need these pages */
-#define MADV_FREE	5		/* free pages only if memory pressure */
 
 /* common parameters: try to keep these consistent across architectures */
+#define MADV_FREE	8		/* free pages only if memory pressure */
 #define MADV_REMOVE	9		/* remove these pages & resources */
 #define MADV_DONTFORK	10		/* don't inherit across fork */
 #define MADV_DOFORK	11		/* do inherit across fork */
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index 7a94102b7a02..869595947873 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -34,9 +34,9 @@
 #define MADV_SEQUENTIAL	2		/* expect sequential page references */
 #define MADV_WILLNEED	3		/* will need these pages */
 #define MADV_DONTNEED	4		/* don't need these pages */
-#define MADV_FREE	5		/* free pages only if memory pressure */
 
 /* common parameters: try to keep these consistent across architectures */
+#define MADV_FREE	8		/* free pages only if memory pressure */
 #define MADV_REMOVE	9		/* remove these pages & resources */
 #define MADV_DONTFORK	10		/* don't inherit across fork */
 #define MADV_DOFORK	11		/* do inherit across fork */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1260270 — Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromHugh Dickins <hughd@google.com>
Date2015-11-02 01:10 +0100
SubjectRe: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qqaRc-6FZ-19@gated-at.bofh.it>
In reply to#1259263
On Fri, 30 Oct 2015, Minchan Kim wrote:
> From: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> For uapi, need try to let all macros have same value, and MADV_FREE is
> added into main branch recently, so need redefine MADV_FREE for it.
> 
> At present, '8' can be shared with all architectures, so redefine it to
> '8'.
> 
> Cc: rth@twiddle.net <rth@twiddle.net>,
> Cc: ink@jurassic.park.msu.ru <ink@jurassic.park.msu.ru>
> Cc: mattst88@gmail.com <mattst88@gmail.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: jejb@parisc-linux.org <jejb@parisc-linux.org>
> Cc: deller@gmx.de <deller@gmx.de>
> Cc: chris@zankel.net <chris@zankel.net>
> Cc: jcmvbkbc@gmail.com <jcmvbkbc@gmail.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-api@vger.kernel.org
> Acked-by: Minchan Kim <minchan@kernel.org>
> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>

Let me add
Acked-by: Hugh Dickins <hughd@google.com>
to this one too.

But I have extended your mail's Cc list: Darrick pointed out earlier
that dietlibc has a Solaris #define MADV_FREE 0x5 in its mman.h,
and that was in the kernel's sparc mman.h up until 2.6.25.  I doubt
that presents any obstacle nowadays, but Dave Miller should be Cc'ed.

I was a little suspicious that 8 is available for MADV_FREE: why did
the common/generic parameters start at 9 instead of 8 back in 2.6.16?
I think the answer is that we had MADV_REMOVE coming in from one
direction, and MADV_DONTFORK coming from another direction, and when
Roland looked for where to start the commons for MADV_DONTFORK, it
appeared that 8 was occupied - by MADV_REMOVE; then a little later
MADV_REMOVE was shifted to become the first of the commons, at 9.

Hugh

> ---
>  arch/alpha/include/uapi/asm/mman.h     | 2 +-
>  arch/mips/include/uapi/asm/mman.h      | 2 +-
>  arch/parisc/include/uapi/asm/mman.h    | 2 +-
>  arch/xtensa/include/uapi/asm/mman.h    | 2 +-
>  include/uapi/asm-generic/mman-common.h | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
> index 836fbd44f65b..0b8a5de7aee3 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -44,9 +44,9 @@
>  #define MADV_WILLNEED	3		/* will need these pages */
>  #define	MADV_SPACEAVAIL	5		/* ensure resources are available */
>  #define MADV_DONTNEED	6		/* don't need these pages */
> -#define MADV_FREE	7		/* free pages only if memory pressure */
>  
>  /* common/generic parameters */
> +#define MADV_FREE	8		/* free pages only if memory pressure */
>  #define MADV_REMOVE	9		/* remove these pages & resources */
>  #define MADV_DONTFORK	10		/* don't inherit across fork */
>  #define MADV_DOFORK	11		/* do inherit across fork */
> diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h
> index 106e741aa7ee..d247f5457944 100644
> --- a/arch/mips/include/uapi/asm/mman.h
> +++ b/arch/mips/include/uapi/asm/mman.h
> @@ -67,9 +67,9 @@
>  #define MADV_SEQUENTIAL 2		/* expect sequential page references */
>  #define MADV_WILLNEED	3		/* will need these pages */
>  #define MADV_DONTNEED	4		/* don't need these pages */
> -#define MADV_FREE	5		/* free pages only if memory pressure */
>  
>  /* common parameters: try to keep these consistent across architectures */
> +#define MADV_FREE	8		/* free pages only if memory pressure */
>  #define MADV_REMOVE	9		/* remove these pages & resources */
>  #define MADV_DONTFORK	10		/* don't inherit across fork */
>  #define MADV_DOFORK	11		/* do inherit across fork */
> diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h
> index 6cb8db76fd4e..700d83fd9352 100644
> --- a/arch/parisc/include/uapi/asm/mman.h
> +++ b/arch/parisc/include/uapi/asm/mman.h
> @@ -40,9 +40,9 @@
>  #define MADV_SPACEAVAIL 5               /* insure that resources are reserved */
>  #define MADV_VPS_PURGE  6               /* Purge pages from VM page cache */
>  #define MADV_VPS_INHERIT 7              /* Inherit parents page size */
> -#define MADV_FREE	8		/* free pages only if memory pressure */
>  
>  /* common/generic parameters */
> +#define MADV_FREE	8		/* free pages only if memory pressure */
>  #define MADV_REMOVE	9		/* remove these pages & resources */
>  #define MADV_DONTFORK	10		/* don't inherit across fork */
>  #define MADV_DOFORK	11		/* do inherit across fork */
> diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
> index 1b19f25bc567..77eaca434071 100644
> --- a/arch/xtensa/include/uapi/asm/mman.h
> +++ b/arch/xtensa/include/uapi/asm/mman.h
> @@ -80,9 +80,9 @@
>  #define MADV_SEQUENTIAL	2		/* expect sequential page references */
>  #define MADV_WILLNEED	3		/* will need these pages */
>  #define MADV_DONTNEED	4		/* don't need these pages */
> -#define MADV_FREE	5		/* free pages only if memory pressure */
>  
>  /* common parameters: try to keep these consistent across architectures */
> +#define MADV_FREE	8		/* free pages only if memory pressure */
>  #define MADV_REMOVE	9		/* remove these pages & resources */
>  #define MADV_DONTFORK	10		/* don't inherit across fork */
>  #define MADV_DOFORK	11		/* do inherit across fork */
> diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
> index 7a94102b7a02..869595947873 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -34,9 +34,9 @@
>  #define MADV_SEQUENTIAL	2		/* expect sequential page references */
>  #define MADV_WILLNEED	3		/* will need these pages */
>  #define MADV_DONTNEED	4		/* don't need these pages */
> -#define MADV_FREE	5		/* free pages only if memory pressure */
>  
>  /* common parameters: try to keep these consistent across architectures */
> +#define MADV_FREE	8		/* free pages only if memory pressure */
>  #define MADV_REMOVE	9		/* remove these pages & resources */
>  #define MADV_DONTFORK	10		/* don't inherit across fork */
>  #define MADV_DOFORK	11		/* do inherit across fork */
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261163 — Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 03:40 +0100
SubjectRe: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qqzFT-50z-1@gated-at.bofh.it>
In reply to#1260270
On Tue, Nov 03, 2015 at 11:32:51AM +0900, Minchan Kim wrote:
> On Sun, Nov 01, 2015 at 04:08:27PM -0800, Hugh Dickins wrote:
> > On Fri, 30 Oct 2015, Minchan Kim wrote:
> > > From: Chen Gang <gang.chen.5i5j@gmail.com>
> > > 
> > > For uapi, need try to let all macros have same value, and MADV_FREE is
> > > added into main branch recently, so need redefine MADV_FREE for it.
> > > 
> > > At present, '8' can be shared with all architectures, so redefine it to
> > > '8'.
> > > 
> > > Cc: rth@twiddle.net <rth@twiddle.net>,
> > > Cc: ink@jurassic.park.msu.ru <ink@jurassic.park.msu.ru>
> > > Cc: mattst88@gmail.com <mattst88@gmail.com>
> > > Cc: Ralf Baechle <ralf@linux-mips.org>
> > > Cc: jejb@parisc-linux.org <jejb@parisc-linux.org>
> > > Cc: deller@gmx.de <deller@gmx.de>
> > > Cc: chris@zankel.net <chris@zankel.net>
> > > Cc: jcmvbkbc@gmail.com <jcmvbkbc@gmail.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: linux-arch@vger.kernel.org
> > > Cc: linux-api@vger.kernel.org
> > > Acked-by: Minchan Kim <minchan@kernel.org>
> > > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> > 
> > Let me add
> > Acked-by: Hugh Dickins <hughd@google.com>
> > to this one too.
> > 
> > But I have extended your mail's Cc list: Darrick pointed out earlier
> > that dietlibc has a Solaris #define MADV_FREE 0x5 in its mman.h,
> > and that was in the kernel's sparc mman.h up until 2.6.25.  I doubt
> > that presents any obstacle nowadays, but Dave Miller should be Cc'ed.

For the convenience for Dave, I found this.

commit ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16
Author: David S. Miller <davem@davemloft.net>
Date:   Sun Apr 20 02:14:23 2008 -0700

    [SPARC]: Remove SunOS and Solaris binary support.
    
    As per Documentation/feature-removal-schedule.txt
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

Hello Dave,
Could you confirm it?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261177 — Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromDavid Miller <davem@davemloft.net>
Date2015-11-03 04:40 +0100
SubjectRe: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qqABY-5Gc-7@gated-at.bofh.it>
In reply to#1261163
From: Minchan Kim <minchan@kernel.org>
Date: Tue, 3 Nov 2015 11:36:51 +0900

> For the convenience for Dave, I found this.
> 
> commit ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16
> Author: David S. Miller <davem@davemloft.net>
> Date:   Sun Apr 20 02:14:23 2008 -0700
> 
>     [SPARC]: Remove SunOS and Solaris binary support.
>     
>     As per Documentation/feature-removal-schedule.txt
>     
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> Hello Dave,
> Could you confirm it?

I don't understand what you want me to confirm.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261193 — Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 05:40 +0100
SubjectRe: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qqBy1-6hw-5@gated-at.bofh.it>
In reply to#1261177
On Mon, Nov 02, 2015 at 10:36:52PM -0500, David Miller wrote:
> From: Minchan Kim <minchan@kernel.org>
> Date: Tue, 3 Nov 2015 11:36:51 +0900
> 
> > For the convenience for Dave, I found this.
> > 
> > commit ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16
> > Author: David S. Miller <davem@davemloft.net>
> > Date:   Sun Apr 20 02:14:23 2008 -0700
> > 
> >     [SPARC]: Remove SunOS and Solaris binary support.
> >     
> >     As per Documentation/feature-removal-schedule.txt
> >     
> >     Signed-off-by: David S. Miller <davem@davemloft.net>
> > 
> > Hello Dave,
> > Could you confirm it?
> 
> I don't understand what you want me to confirm.

Sorry for lacking of the information.

Is it okay to use number 8 for upcoming madvise(addr, len, MADV_FREE)
feature in sparc arch?

The reason to ask is that Darrick pointed out earlier that
dietlibc has a Solaris #define MADV_FREE 0x5 in its mman.h
and Hugh pointed out that was in the kernel's sparc mman.h up
until 2.6.25 but disappeared now so I guess it's okay to use the
number 8 for MADV_FREE in sparc but want to confirm from you.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261166 — Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 03:40 +0100
SubjectRe: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
Message-ID<qqzFT-50z-3@gated-at.bofh.it>
In reply to#1260270
On Sun, Nov 01, 2015 at 04:08:27PM -0800, Hugh Dickins wrote:
> On Fri, 30 Oct 2015, Minchan Kim wrote:
> > From: Chen Gang <gang.chen.5i5j@gmail.com>
> > 
> > For uapi, need try to let all macros have same value, and MADV_FREE is
> > added into main branch recently, so need redefine MADV_FREE for it.
> > 
> > At present, '8' can be shared with all architectures, so redefine it to
> > '8'.
> > 
> > Cc: rth@twiddle.net <rth@twiddle.net>,
> > Cc: ink@jurassic.park.msu.ru <ink@jurassic.park.msu.ru>
> > Cc: mattst88@gmail.com <mattst88@gmail.com>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: jejb@parisc-linux.org <jejb@parisc-linux.org>
> > Cc: deller@gmx.de <deller@gmx.de>
> > Cc: chris@zankel.net <chris@zankel.net>
> > Cc: jcmvbkbc@gmail.com <jcmvbkbc@gmail.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: linux-arch@vger.kernel.org
> > Cc: linux-api@vger.kernel.org
> > Acked-by: Minchan Kim <minchan@kernel.org>
> > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> Let me add
> Acked-by: Hugh Dickins <hughd@google.com>
> to this one too.
> 
> But I have extended your mail's Cc list: Darrick pointed out earlier
> that dietlibc has a Solaris #define MADV_FREE 0x5 in its mman.h,
> and that was in the kernel's sparc mman.h up until 2.6.25.  I doubt
> that presents any obstacle nowadays, but Dave Miller should be Cc'ed.
> 
> I was a little suspicious that 8 is available for MADV_FREE: why did
> the common/generic parameters start at 9 instead of 8 back in 2.6.16?
> I think the answer is that we had MADV_REMOVE coming in from one
> direction, and MADV_DONTFORK coming from another direction, and when
> Roland looked for where to start the commons for MADV_DONTFORK, it
> appeared that 8 was occupied - by MADV_REMOVE; then a little later
> MADV_REMOVE was shifted to become the first of the commons, at 9.

Thanks for Ack, Ccing relevant people and history!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259264 — [PATCH 1/8] mm: support madvise(MADV_FREE)

FromMinchan Kim <minchan@kernel.org>
Date2015-10-30 08:10 +0100
Subject[PATCH 1/8] mm: support madvise(MADV_FREE)
Message-ID<qpbZ0-2NI-23@gated-at.bofh.it>
In reply to#1259262
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).

Jason Evans said:

: Facebook has been using MAP_UNINITIALIZED
: (https://lkml.org/lkml/2012/1/18/308) in some of its applications for
: several years, but there are operational costs to maintaining this
: out-of-tree in our kernel and in jemalloc, and we are anxious to retire it
: in favor of MADV_FREE.  When we first enabled MAP_UNINITIALIZED it
: increased throughput for much of our workload by ~5%, and although the
: benefit has decreased using newer hardware and kernels, there is still
: enough benefit that we cannot reasonably retire it without a replacement.
:
: Aside from Facebook operations, there are numerous broadly used
: applications that would benefit from MADV_FREE.  The ones that immediately
: come to mind are redis, varnish, and MariaDB.  I don't have much insight
: into Android internals and development process, but I would hope to see
: MADV_FREE support eventually end up there as well to benefit applications
: linked with the integrated jemalloc.
:
: jemalloc will use MADV_FREE once it becomes available in the Linux kernel.
: In fact, jemalloc already uses MADV_FREE or equivalent everywhere it's
: available: *BSD, OS X, Windows, and Solaris -- every platform except Linux
: (and AIX, but I'm not sure it even compiles on AIX).  The lack of
: MADV_FREE on Linux forced me down a long series of increasingly
: sophisticated heuristics for madvise() volume reduction, and even so this
: remains a common performance issue for people using jemalloc on Linux.
: Please integrate MADV_FREE; many people will benefit substantially.

How it works:

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)

barrios@blaptop:~/benchmark/ebizzy$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                12
On-line CPU(s) list:   0-11
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             12
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 2
Stepping:              3
CPU MHz:               3200.185
BogoMIPS:              6400.53
Virtualization:        VT-x
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
NUMA node0 CPU(s):     0-11
ebizzy benchmark(./ebizzy -S 10 -n 512)

Higher avg is better.

 vanilla-jemalloc		MADV_free-jemalloc

1 thread
records: 10			    records: 10
avg:	2961.90			    avg:   12069.70
std:	  71.96(2.43%)		    std:     186.68(1.55%)
max:	3070.00			    max:   12385.00
min:	2796.00			    min:   11746.00

2 thread
records: 10			    records: 10
avg:	5020.00			    avg:   17827.00
std:	 264.87(5.28%)		    std:     358.52(2.01%)
max:	5244.00			    max:   18760.00
min:	4251.00			    min:   17382.00

4 thread
records: 10			    records: 10
avg:	8988.80			    avg:   27930.80
std:	1175.33(13.08%)		    std:    3317.33(11.88%)
max:	9508.00			    max:   30879.00
min:	5477.00			    min:   21024.00

8 thread
records: 10			    records: 10
avg:   13036.50			    avg:   33739.40
std:	 170.67(1.31%)		    std:    5146.22(15.25%)
max:   13371.00			    max:   40572.00
min:   12785.00			    min:   24088.00

16 thread
records: 10			    records: 10
avg:   11092.40			    avg:   31424.20
std:	 710.60(6.41%)		    std:    3763.89(11.98%)
max:   12446.00			    max:   36635.00
min:	9949.00			    min:   25669.00

32 thread
records: 10			    records: 10
avg:   11067.00			    avg:   34495.80
std:	 971.06(8.77%)		    std:    2721.36(7.89%)
max:   12010.00			    max:   38598.00
min:	9002.00			    min:   30636.00

In summary, MADV_FREE is about much faster than MADV_DONTNEED.

Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 include/linux/rmap.h                   |   1 +
 include/linux/vm_event_item.h          |   1 +
 include/uapi/asm-generic/mman-common.h |   1 +
 mm/madvise.c                           | 128 +++++++++++++++++++++++++++++++++
 mm/rmap.c                              |   7 ++
 mm/swap_state.c                        |   5 +-
 mm/vmscan.c                            |  10 ++-
 mm/vmstat.c                            |   1 +
 8 files changed, 149 insertions(+), 5 deletions(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 29446aeef36e..f4c992826242 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -85,6 +85,7 @@ enum ttu_flags {
 	TTU_UNMAP = 1,			/* unmap mode */
 	TTU_MIGRATION = 2,		/* migration mode */
 	TTU_MUNLOCK = 4,		/* munlock mode */
+	TTU_FREE = 8,			/* free mode */
 
 	TTU_IGNORE_MLOCK = (1 << 8),	/* ignore mlock */
 	TTU_IGNORE_ACCESS = (1 << 9),	/* don't age */
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 9246d32dc973..2b1cef88b827 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -25,6 +25,7 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
 		FOR_ALL_ZONES(PGALLOC),
 		PGFREE, PGACTIVATE, PGDEACTIVATE,
 		PGFAULT, PGMAJFAULT,
+		PGLAZYFREED,
 		FOR_ALL_ZONES(PGREFILL),
 		FOR_ALL_ZONES(PGSTEAL_KSWAPD),
 		FOR_ALL_ZONES(PGSTEAL_DIRECT),
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index ddc3b36f1046..7a94102b7a02 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -34,6 +34,7 @@
 #define MADV_SEQUENTIAL	2		/* expect sequential page references */
 #define MADV_WILLNEED	3		/* will need these pages */
 #define MADV_DONTNEED	4		/* don't need these pages */
+#define MADV_FREE	5		/* free pages only if memory pressure */
 
 /* common parameters: try to keep these consistent across architectures */
 #define MADV_REMOVE	9		/* remove these pages & resources */
diff --git a/mm/madvise.c b/mm/madvise.c
index c889fcbb530e..640311704e31 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -20,6 +20,9 @@
 #include <linux/backing-dev.h>
 #include <linux/swap.h>
 #include <linux/swapops.h>
+#include <linux/mmu_notifier.h>
+
+#include <asm/tlb.h>
 
 /*
  * Any behaviour which results in changes to the vma->vm_flags needs to
@@ -32,6 +35,7 @@ static int madvise_need_mmap_write(int behavior)
 	case MADV_REMOVE:
 	case MADV_WILLNEED:
 	case MADV_DONTNEED:
+	case MADV_FREE:
 		return 0;
 	default:
 		/* be safe, default to 1. list exceptions explicitly */
@@ -256,6 +260,121 @@ static long madvise_willneed(struct vm_area_struct *vma,
 	return 0;
 }
 
+static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
+				unsigned long end, struct mm_walk *walk)
+
+{
+	struct mmu_gather *tlb = walk->private;
+	struct mm_struct *mm = tlb->mm;
+	struct vm_area_struct *vma = walk->vma;
+	spinlock_t *ptl;
+	pte_t *pte, ptent;
+	struct page *page;
+
+	split_huge_page_pmd(vma, addr, pmd);
+	if (pmd_trans_unstable(pmd))
+		return 0;
+
+	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
+	arch_enter_lazy_mmu_mode();
+	for (; addr != end; pte++, addr += PAGE_SIZE) {
+		ptent = *pte;
+
+		if (!pte_present(ptent))
+			continue;
+
+		page = vm_normal_page(vma, addr, ptent);
+		if (!page)
+			continue;
+
+		if (PageSwapCache(page)) {
+			if (!trylock_page(page))
+				continue;
+
+			if (!try_to_free_swap(page)) {
+				unlock_page(page);
+				continue;
+			}
+
+			ClearPageDirty(page);
+			unlock_page(page);
+		}
+
+		/*
+		 * Some of architecture(ex, PPC) don't update TLB
+		 * with set_pte_at and tlb_remove_tlb_entry so for
+		 * the portability, remap the pte with old|clean
+		 * after pte clearing.
+		 */
+		ptent = ptep_get_and_clear_full(mm, addr, pte,
+						tlb->fullmm);
+		ptent = pte_mkold(ptent);
+		ptent = pte_mkclean(ptent);
+		set_pte_at(mm, addr, pte, ptent);
+		tlb_remove_tlb_entry(tlb, pte, addr);
+	}
+	arch_leave_lazy_mmu_mode();
+	pte_unmap_unlock(pte - 1, ptl);
+	cond_resched();
+	return 0;
+}
+
+static void madvise_free_page_range(struct mmu_gather *tlb,
+			     struct vm_area_struct *vma,
+			     unsigned long addr, unsigned long end)
+{
+	struct mm_walk free_walk = {
+		.pmd_entry = madvise_free_pte_range,
+		.mm = vma->vm_mm,
+		.private = tlb,
+	};
+
+	tlb_start_vma(tlb, vma);
+	walk_page_range(addr, end, &free_walk);
+	tlb_end_vma(tlb, vma);
+}
+
+static int madvise_free_single_vma(struct vm_area_struct *vma,
+			unsigned long start_addr, unsigned long end_addr)
+{
+	unsigned long start, end;
+	struct mm_struct *mm = vma->vm_mm;
+	struct mmu_gather tlb;
+
+	if (vma->vm_flags & (VM_LOCKED|VM_HUGETLB|VM_PFNMAP))
+		return -EINVAL;
+
+	/* MADV_FREE works for only anon vma at the moment */
+	if (!vma_is_anonymous(vma))
+		return -EINVAL;
+
+	start = max(vma->vm_start, start_addr);
+	if (start >= vma->vm_end)
+		return -EINVAL;
+	end = min(vma->vm_end, end_addr);
+	if (end <= vma->vm_start)
+		return -EINVAL;
+
+	lru_add_drain();
+	tlb_gather_mmu(&tlb, mm, start, end);
+	update_hiwater_rss(mm);
+
+	mmu_notifier_invalidate_range_start(mm, start, end);
+	madvise_free_page_range(&tlb, vma, start, end);
+	mmu_notifier_invalidate_range_end(mm, start, end);
+	tlb_finish_mmu(&tlb, start, end);
+
+	return 0;
+}
+
+static long madvise_free(struct vm_area_struct *vma,
+			     struct vm_area_struct **prev,
+			     unsigned long start, unsigned long end)
+{
+	*prev = vma;
+	return madvise_free_single_vma(vma, start, end);
+}
+
 /*
  * Application no longer needs these pages.  If the pages are dirty,
  * it's OK to just throw them away.  The app will be more careful about
@@ -379,6 +498,14 @@ madvise_vma(struct vm_area_struct *vma, struct vm_area_struct **prev,
 		return madvise_remove(vma, prev, start, end);
 	case MADV_WILLNEED:
 		return madvise_willneed(vma, prev, start, end);
+	case MADV_FREE:
+		/*
+		 * XXX: In this implementation, MADV_FREE works like
+		 * MADV_DONTNEED on swapless system or full swap.
+		 */
+		if (get_nr_swap_pages() > 0)
+			return madvise_free(vma, prev, start, end);
+		/* passthrough */
 	case MADV_DONTNEED:
 		return madvise_dontneed(vma, prev, start, end);
 	default:
@@ -398,6 +525,7 @@ madvise_behavior_valid(int behavior)
 	case MADV_REMOVE:
 	case MADV_WILLNEED:
 	case MADV_DONTNEED:
+	case MADV_FREE:
 #ifdef CONFIG_KSM
 	case MADV_MERGEABLE:
 	case MADV_UNMERGEABLE:
diff --git a/mm/rmap.c b/mm/rmap.c
index f5b5c1f3dcd7..9449e91839ab 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1374,6 +1374,12 @@ static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
 		swp_entry_t entry = { .val = page_private(page) };
 		pte_t swp_pte;
 
+		if (!PageDirty(page) && (flags & TTU_FREE)) {
+			/* It's a freeable page by MADV_FREE */
+			dec_mm_counter(mm, MM_ANONPAGES);
+			goto discard;
+		}
+
 		if (PageSwapCache(page)) {
 			/*
 			 * Store the swap location in the pte.
@@ -1414,6 +1420,7 @@ static int try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
 	} else
 		dec_mm_counter(mm, MM_FILEPAGES);
 
+discard:
 	page_remove_rmap(page);
 	page_cache_release(page);
 
diff --git a/mm/swap_state.c b/mm/swap_state.c
index d504adb7fa5f..10f63eded7b7 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -185,13 +185,12 @@ int add_to_swap(struct page *page, struct list_head *list)
 	 * deadlock in the swap out path.
 	 */
 	/*
-	 * Add it to the swap cache and mark it dirty
+	 * Add it to the swap cache.
 	 */
 	err = add_to_swap_cache(page, entry,
 			__GFP_HIGH|__GFP_NOMEMALLOC|__GFP_NOWARN);
 
-	if (!err) {	/* Success */
-		SetPageDirty(page);
+	if (!err) {
 		return 1;
 	} else {	/* -ENOMEM radix-tree allocation failure */
 		/*
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7f63a9381f71..7a415b9fdd34 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -906,6 +906,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 		int may_enter_fs;
 		enum page_references references = PAGEREF_RECLAIM_CLEAN;
 		bool dirty, writeback;
+		bool freeable = false;
 
 		cond_resched();
 
@@ -1049,6 +1050,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 				goto keep_locked;
 			if (!add_to_swap(page, page_list))
 				goto activate_locked;
+			freeable = true;
 			may_enter_fs = 1;
 
 			/* Adding to swap updated mapping */
@@ -1060,8 +1062,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 		 * processes. Try to unmap it here.
 		 */
 		if (page_mapped(page) && mapping) {
-			switch (try_to_unmap(page,
-					ttu_flags|TTU_BATCH_FLUSH)) {
+			switch (try_to_unmap(page, freeable ?
+				(ttu_flags | TTU_BATCH_FLUSH | TTU_FREE) :
+				(ttu_flags | TTU_BATCH_FLUSH))) {
 			case SWAP_FAIL:
 				goto activate_locked;
 			case SWAP_AGAIN:
@@ -1186,6 +1189,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 		 */
 		__clear_page_locked(page);
 free_it:
+		if (freeable && !PageDirty(page))
+			count_vm_event(PGLAZYFREED);
+
 		nr_reclaimed++;
 
 		/*
diff --git a/mm/vmstat.c b/mm/vmstat.c
index fbf14485a049..59d45b22355f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -759,6 +759,7 @@ const char * const vmstat_text[] = {
 
 	"pgfault",
 	"pgmajfault",
+	"pglazyfreed",
 
 	TEXTS_FOR_ZONES("pgrefill")
 	TEXTS_FOR_ZONES("pgsteal_kswapd")
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259624 — Re: [PATCH 1/8] mm: support madvise(MADV_FREE)

FromShaohua Li <shli@kernel.org>
Date2015-10-30 17:50 +0100
SubjectRe: [PATCH 1/8] mm: support madvise(MADV_FREE)
Message-ID<qpl2j-8b8-29@gated-at.bofh.it>
In reply to#1259264
On Fri, Oct 30, 2015 at 04:01:37PM +0900, Minchan Kim wrote:
> +static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> +				unsigned long end, struct mm_walk *walk)
> +
> +{
> +	struct mmu_gather *tlb = walk->private;
> +	struct mm_struct *mm = tlb->mm;
> +	struct vm_area_struct *vma = walk->vma;
> +	spinlock_t *ptl;
> +	pte_t *pte, ptent;
> +	struct page *page;
> +
> +	split_huge_page_pmd(vma, addr, pmd);
> +	if (pmd_trans_unstable(pmd))
> +		return 0;
> +
> +	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
> +	arch_enter_lazy_mmu_mode();
> +	for (; addr != end; pte++, addr += PAGE_SIZE) {
> +		ptent = *pte;
> +
> +		if (!pte_present(ptent))
> +			continue;
> +
> +		page = vm_normal_page(vma, addr, ptent);
> +		if (!page)
> +			continue;
> +
> +		if (PageSwapCache(page)) {
> +			if (!trylock_page(page))
> +				continue;
> +
> +			if (!try_to_free_swap(page)) {
> +				unlock_page(page);
> +				continue;
> +			}
> +
> +			ClearPageDirty(page);
> +			unlock_page(page);
> +		}
> +
> +		/*
> +		 * Some of architecture(ex, PPC) don't update TLB
> +		 * with set_pte_at and tlb_remove_tlb_entry so for
> +		 * the portability, remap the pte with old|clean
> +		 * after pte clearing.
> +		 */
> +		ptent = ptep_get_and_clear_full(mm, addr, pte,
> +						tlb->fullmm);
> +		ptent = pte_mkold(ptent);
> +		ptent = pte_mkclean(ptent);
> +		set_pte_at(mm, addr, pte, ptent);
> +		tlb_remove_tlb_entry(tlb, pte, addr);

The orginal ptent might not be dirty. In that case, the tlb_remove_tlb_entry
is unnecessary, so please add a check. In practice, I saw more TLB flush with
FREE compared to DONTNEED because of this issue.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261074 — Re: [PATCH 1/8] mm: support madvise(MADV_FREE)

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 01:20 +0100
SubjectRe: [PATCH 1/8] mm: support madvise(MADV_FREE)
Message-ID<qqxup-3IW-7@gated-at.bofh.it>
In reply to#1259624
On Fri, Oct 30, 2015 at 09:49:37AM -0700, Shaohua Li wrote:
> On Fri, Oct 30, 2015 at 04:01:37PM +0900, Minchan Kim wrote:
> > +static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> > +				unsigned long end, struct mm_walk *walk)
> > +
> > +{
> > +	struct mmu_gather *tlb = walk->private;
> > +	struct mm_struct *mm = tlb->mm;
> > +	struct vm_area_struct *vma = walk->vma;
> > +	spinlock_t *ptl;
> > +	pte_t *pte, ptent;
> > +	struct page *page;
> > +
> > +	split_huge_page_pmd(vma, addr, pmd);
> > +	if (pmd_trans_unstable(pmd))
> > +		return 0;
> > +
> > +	pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
> > +	arch_enter_lazy_mmu_mode();
> > +	for (; addr != end; pte++, addr += PAGE_SIZE) {
> > +		ptent = *pte;
> > +
> > +		if (!pte_present(ptent))
> > +			continue;
> > +
> > +		page = vm_normal_page(vma, addr, ptent);
> > +		if (!page)
> > +			continue;
> > +
> > +		if (PageSwapCache(page)) {
> > +			if (!trylock_page(page))
> > +				continue;
> > +
> > +			if (!try_to_free_swap(page)) {
> > +				unlock_page(page);
> > +				continue;
> > +			}
> > +
> > +			ClearPageDirty(page);
> > +			unlock_page(page);
> > +		}
> > +
> > +		/*
> > +		 * Some of architecture(ex, PPC) don't update TLB
> > +		 * with set_pte_at and tlb_remove_tlb_entry so for
> > +		 * the portability, remap the pte with old|clean
> > +		 * after pte clearing.
> > +		 */
> > +		ptent = ptep_get_and_clear_full(mm, addr, pte,
> > +						tlb->fullmm);
> > +		ptent = pte_mkold(ptent);
> > +		ptent = pte_mkclean(ptent);
> > +		set_pte_at(mm, addr, pte, ptent);
> > +		tlb_remove_tlb_entry(tlb, pte, addr);
> 
> The orginal ptent might not be dirty. In that case, the tlb_remove_tlb_entry
> is unnecessary, so please add a check. In practice, I saw more TLB flush with
> FREE compared to DONTNEED because of this issue.

Actually, it was my TODO but I forgot it. :(
I fixed for new version.
Thanks for the pointing out.

> 
> Thanks,
> Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259266 — [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced

FromMinchan Kim <minchan@kernel.org>
Date2015-10-30 08:10 +0100
Subject[PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced
Message-ID<qpbZ0-2NI-29@gated-at.bofh.it>
In reply to#1259262
deactivate_page aims for accelerate for reclaiming through
moving pages from active list to inactive list so we should
clear PG_referenced for the goal.

Acked-by: Hugh Dickins <hughd@google.com>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 mm/swap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/swap.c b/mm/swap.c
index d0eacc5f62a3..4a6aec976ab1 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -810,6 +810,7 @@ static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec,
 
 		del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
 		ClearPageActive(page);
+		ClearPageReferenced(page);
 		add_page_to_lru_list(page, lruvec, lru);
 
 		__count_vm_event(PGDEACTIVATE);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259476 — Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced

FromMichal Hocko <mhocko@kernel.org>
Date2015-10-30 13:50 +0100
SubjectRe: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced
Message-ID<qphi2-5Rm-17@gated-at.bofh.it>
In reply to#1259266
On Fri 30-10-15 16:01:42, Minchan Kim wrote:
> deactivate_page aims for accelerate for reclaiming through
> moving pages from active list to inactive list so we should
> clear PG_referenced for the goal.

I might be missing something but aren't we using PG_referenced only for
pagecache (and shmem) pages?

> 
> Acked-by: Hugh Dickins <hughd@google.com>
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
>  mm/swap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/swap.c b/mm/swap.c
> index d0eacc5f62a3..4a6aec976ab1 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -810,6 +810,7 @@ static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec,
>  
>  		del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
>  		ClearPageActive(page);
> +		ClearPageReferenced(page);
>  		add_page_to_lru_list(page, lruvec, lru);
>  
>  		__count_vm_event(PGDEACTIVATE);
> -- 
> 1.9.1

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261106 — Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 02:20 +0100
SubjectRe: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced
Message-ID<qqyqu-4js-7@gated-at.bofh.it>
In reply to#1259476
On Fri, Oct 30, 2015 at 01:47:11PM +0100, Michal Hocko wrote:
> On Fri 30-10-15 16:01:42, Minchan Kim wrote:
> > deactivate_page aims for accelerate for reclaiming through
> > moving pages from active list to inactive list so we should
> > clear PG_referenced for the goal.
> 
> I might be missing something but aren't we using PG_referenced only for
> pagecache (and shmem) pages?

You don't miss anything. For pages which are candidate of MADV_FREEing(
ie, normal anonymous page, not shmem, tmpfs), they shouldn't have any
PG_referenced. Although normal anonymous pages have it, VM doesn't respect
it. One thing I suspect is GUP with FOLL_TOUCH which calls mark_page_accesssed
on anonymous page and will mark PG_referenced.
Technically, it's not a problem but just want to notice in this time.

Primary reason was I want to make deactivate_page *general* so it could
be used for file page as well as anon pages in future.
But at the moment, user of deactivate_page is only MADV_FREE so it might
be better to merge the logic for anon page deactivation into
deactivate_file_page and rename it as general "deactivate_page"
if you're thinking it's better.

> 
> > 
> > Acked-by: Hugh Dickins <hughd@google.com>
> > Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> >  mm/swap.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/mm/swap.c b/mm/swap.c
> > index d0eacc5f62a3..4a6aec976ab1 100644
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -810,6 +810,7 @@ static void lru_deactivate_fn(struct page *page, struct lruvec *lruvec,
> >  
> >  		del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
> >  		ClearPageActive(page);
> > +		ClearPageReferenced(page);
> >  		add_page_to_lru_list(page, lruvec, lru);
> >  
> >  		__count_vm_event(PGDEACTIVATE);
> > -- 
> > 1.9.1
> 
> -- 
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1262124 — Re: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced

FromMichal Hocko <mhocko@kernel.org>
Date2015-11-04 09:30 +0100
SubjectRe: [PATCH 6/8] mm: lru_deactivate_fn should clear PG_referenced
Message-ID<qr1C9-6qv-3@gated-at.bofh.it>
In reply to#1261106
On Tue 03-11-15 10:10:30, Minchan Kim wrote:
> One thing I suspect is GUP with FOLL_TOUCH which calls mark_page_accesssed
> on anonymous page and will mark PG_referenced.

OK, this is what I've missed.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259267 — [PATCH 4/8] mm: free swp_entry in madvise_free

FromMinchan Kim <minchan@kernel.org>
Date2015-10-30 08:10 +0100
Subject[PATCH 4/8] mm: free swp_entry in madvise_free
Message-ID<qpbZ0-2NI-31@gated-at.bofh.it>
In reply to#1259262
When I test below piece of code with 12 processes(ie, 512M * 12 = 6G
consume) on my (3G ram + 12 cpu + 8G swap, the madvise_free is siginficat
slower (ie, 2x times) than madvise_dontneed.

loop = 5;
mmap(512M);
while (loop--) {
        memset(512M);
        madvise(MADV_FREE or MADV_DONTNEED);
}

The reason is lots of swapin.

1) dontneed: 1,612 swapin
2) madvfree: 879,585 swapin

If we find hinted pages were already swapped out when syscall is called,
it's pointless to keep the swapped-out pages in pte.
Instead, let's free the cold page because swapin is more expensive
than (alloc page + zeroing).

With this patch, it reduced swapin from 879,585 to 1,878 so elapsed time

1) dontneed: 6.10user 233.50system 0:50.44elapsed
2) madvfree: 6.03user 401.17system 1:30.67elapsed
2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed

Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 mm/madvise.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 640311704e31..663bd9fa0ae0 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -270,6 +270,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	spinlock_t *ptl;
 	pte_t *pte, ptent;
 	struct page *page;
+	swp_entry_t entry;
+	int nr_swap = 0;
 
 	split_huge_page_pmd(vma, addr, pmd);
 	if (pmd_trans_unstable(pmd))
@@ -280,8 +282,22 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 	for (; addr != end; pte++, addr += PAGE_SIZE) {
 		ptent = *pte;
 
-		if (!pte_present(ptent))
+		if (pte_none(ptent))
 			continue;
+		/*
+		 * If the pte has swp_entry, just clear page table to
+		 * prevent swap-in which is more expensive rather than
+		 * (page allocation + zeroing).
+		 */
+		if (!pte_present(ptent)) {
+			entry = pte_to_swp_entry(ptent);
+			if (non_swap_entry(entry))
+				continue;
+			nr_swap--;
+			free_swap_and_cache(entry);
+			pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
+			continue;
+		}
 
 		page = vm_normal_page(vma, addr, ptent);
 		if (!page)
@@ -313,6 +329,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
 		set_pte_at(mm, addr, pte, ptent);
 		tlb_remove_tlb_entry(tlb, pte, addr);
 	}
+
+	if (nr_swap) {
+		if (current->mm == mm)
+			sync_mm_rss(mm);
+
+		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
+	}
+
 	arch_leave_lazy_mmu_mode();
 	pte_unmap_unlock(pte - 1, ptl);
 	cond_resched();
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1259468 — Re: [PATCH 4/8] mm: free swp_entry in madvise_free

FromMichal Hocko <mhocko@kernel.org>
Date2015-10-30 13:30 +0100
SubjectRe: [PATCH 4/8] mm: free swp_entry in madvise_free
Message-ID<qpgYG-5KW-25@gated-at.bofh.it>
In reply to#1259267
On Fri 30-10-15 16:01:40, Minchan Kim wrote:
> When I test below piece of code with 12 processes(ie, 512M * 12 = 6G
> consume) on my (3G ram + 12 cpu + 8G swap, the madvise_free is siginficat
> slower (ie, 2x times) than madvise_dontneed.
> 
> loop = 5;
> mmap(512M);
> while (loop--) {
>         memset(512M);
>         madvise(MADV_FREE or MADV_DONTNEED);
> }
> 
> The reason is lots of swapin.
> 
> 1) dontneed: 1,612 swapin
> 2) madvfree: 879,585 swapin
> 
> If we find hinted pages were already swapped out when syscall is called,
> it's pointless to keep the swapped-out pages in pte.
> Instead, let's free the cold page because swapin is more expensive
> than (alloc page + zeroing).
> 
> With this patch, it reduced swapin from 879,585 to 1,878 so elapsed time
> 
> 1) dontneed: 6.10user 233.50system 0:50.44elapsed
> 2) madvfree: 6.03user 401.17system 1:30.67elapsed
> 2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed
> 
> Acked-by: Hugh Dickins <hughd@google.com>
> Signed-off-by: Minchan Kim <minchan@kernel.org>

Yes this makes a lot of sense.

Acked-by: Michal Hocko <mhocko@suse.com>

One nit below.

> ---
>  mm/madvise.c | 26 +++++++++++++++++++++++++-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 640311704e31..663bd9fa0ae0 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -270,6 +270,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	spinlock_t *ptl;
>  	pte_t *pte, ptent;
>  	struct page *page;
> +	swp_entry_t entry;

This could go into !pte_present if block

> +	int nr_swap = 0;
>  
>  	split_huge_page_pmd(vma, addr, pmd);
>  	if (pmd_trans_unstable(pmd))
> @@ -280,8 +282,22 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  	for (; addr != end; pte++, addr += PAGE_SIZE) {
>  		ptent = *pte;
>  
> -		if (!pte_present(ptent))
> +		if (pte_none(ptent))
>  			continue;
> +		/*
> +		 * If the pte has swp_entry, just clear page table to
> +		 * prevent swap-in which is more expensive rather than
> +		 * (page allocation + zeroing).
> +		 */
> +		if (!pte_present(ptent)) {
> +			entry = pte_to_swp_entry(ptent);
> +			if (non_swap_entry(entry))
> +				continue;
> +			nr_swap--;
> +			free_swap_and_cache(entry);
> +			pte_clear_not_present_full(mm, addr, pte, tlb->fullmm);
> +			continue;
> +		}
>  
>  		page = vm_normal_page(vma, addr, ptent);
>  		if (!page)
> @@ -313,6 +329,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
>  		set_pte_at(mm, addr, pte, ptent);
>  		tlb_remove_tlb_entry(tlb, pte, addr);
>  	}
> +
> +	if (nr_swap) {
> +		if (current->mm == mm)
> +			sync_mm_rss(mm);
> +
> +		add_mm_counter(mm, MM_SWAPENTS, nr_swap);
> +	}
> +
>  	arch_leave_lazy_mmu_mode();
>  	pte_unmap_unlock(pte - 1, ptl);
>  	cond_resched();
> -- 
> 1.9.1

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1261093 — Re: [PATCH 4/8] mm: free swp_entry in madvise_free

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 02:00 +0100
SubjectRe: [PATCH 4/8] mm: free swp_entry in madvise_free
Message-ID<qqy77-3Xq-1@gated-at.bofh.it>
In reply to#1259468
On Fri, Oct 30, 2015 at 01:28:14PM +0100, Michal Hocko wrote:
> On Fri 30-10-15 16:01:40, Minchan Kim wrote:
> > When I test below piece of code with 12 processes(ie, 512M * 12 = 6G
> > consume) on my (3G ram + 12 cpu + 8G swap, the madvise_free is siginficat
> > slower (ie, 2x times) than madvise_dontneed.
> > 
> > loop = 5;
> > mmap(512M);
> > while (loop--) {
> >         memset(512M);
> >         madvise(MADV_FREE or MADV_DONTNEED);
> > }
> > 
> > The reason is lots of swapin.
> > 
> > 1) dontneed: 1,612 swapin
> > 2) madvfree: 879,585 swapin
> > 
> > If we find hinted pages were already swapped out when syscall is called,
> > it's pointless to keep the swapped-out pages in pte.
> > Instead, let's free the cold page because swapin is more expensive
> > than (alloc page + zeroing).
> > 
> > With this patch, it reduced swapin from 879,585 to 1,878 so elapsed time
> > 
> > 1) dontneed: 6.10user 233.50system 0:50.44elapsed
> > 2) madvfree: 6.03user 401.17system 1:30.67elapsed
> > 2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed
> > 
> > Acked-by: Hugh Dickins <hughd@google.com>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> 
> Yes this makes a lot of sense.
> 
> Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

> 
> One nit below.
> 
> > ---
> >  mm/madvise.c | 26 +++++++++++++++++++++++++-
> >  1 file changed, 25 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 640311704e31..663bd9fa0ae0 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -270,6 +270,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
> >  	spinlock_t *ptl;
> >  	pte_t *pte, ptent;
> >  	struct page *page;
> > +	swp_entry_t entry;
> 
> This could go into !pte_present if block

Sure, I fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1260082

FromDavid Rientjes <rientjes@google.com>
Date2015-11-01 06:00 +0100
Message-ID<qpSUh-3IE-1@gated-at.bofh.it>
In reply to#1259262
On Fri, 30 Oct 2015, Minchan Kim wrote:

> MADV_FREE is on linux-next so long time. The reason was two, I think.
> 
> 1. MADV_FREE code on reclaim path was really mess.
> 
> 2. Andrew really want to see voice of userland people who want to use
>    the syscall.
> 
> A few month ago, Daniel Micay(jemalloc active contributor) requested me
> to make progress upstreaming but I was busy at that time so it took
> so long time for me to revist the code and finally, I clean it up the
> mess recently so it solves the #2 issue.
> 
> As well, Daniel and Jason(jemalloc maintainer) requested it to Andrew
> again recently and they said it would be great to have even though
> it has swap dependency now so Andrew decided he will do that for v4.4.
> 

First, thanks very much for refreshing the patchset and reposting after a 
series of changes have been periodically added to -mm, it makes it much 
easier.

For tcmalloc, we can do some things in the allocator itself to increase 
the amount of memory backed by thp.  Specifically, we can prefer to 
release Spans to pageblocks that are already not backed by thp so there is 
no additional split on each scavenge.  This is somewhat easy if all memory 
is organized into hugepage-aligned pageblocks in the allocator itself.  
Second, we can prefer to release Spans of longer length on each scavenge 
so we can delay scavenging for as long as possible in a hope we can find 
more pages to coalesce.  Third, we can discount refaulted released memory 
from the scavenging period.

That significantly improves the amount of memory backed by thp for 
tcmalloc.  The problem, however, is that tcmalloc uses MADV_DONTNEED to 
release memory to the system and MADV_FREE wouldn't help at all in a 
swapless environment.

To combat that, I've proposed a new MADV bit that simply caches the 
ranges freed by the allocator per vma and places them on both a per-vma 
and per-memcg list.  During reclaim, this list is iterated and ptes are 
freed after thp split period to the normal directed reclaim.  Without 
memory pressure, this backs 100% of the heap with thp with a relatively 
lightweight kernel change (the majority is vma manipulation on split) and 
a couple line change to tcmalloc.  When pulling memory from the returned 
freelists, the memory that we have MADV_DONTNEED'd, we need to use another 
MADV bit to remove it from this cache, so there is a second madvise(2) 
syscall involved but the freeing call is much less expensive since there 
is no pagetable walk without memory pressure or synchronous thp split.

I've been looking at MADV_FREE to see if there is common ground that could 
be shared, but perhaps it's just easier to ask what your proposed strategy 
is so that tcmalloc users, especially those in swapless environments, 
would benefit from any of your work?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1260084

FromDaniel Micay <danielmicay@gmail.com>
Date2015-11-01 07:40 +0100
Message-ID<qpUt4-4P2-1@gated-at.bofh.it>
In reply to#1260082

[Multipart message — attachments visible in raw view] — view raw

On 01/11/15 12:51 AM, David Rientjes wrote:
> On Fri, 30 Oct 2015, Minchan Kim wrote:
> 
>> MADV_FREE is on linux-next so long time. The reason was two, I think.
>>
>> 1. MADV_FREE code on reclaim path was really mess.
>>
>> 2. Andrew really want to see voice of userland people who want to use
>>    the syscall.
>>
>> A few month ago, Daniel Micay(jemalloc active contributor) requested me
>> to make progress upstreaming but I was busy at that time so it took
>> so long time for me to revist the code and finally, I clean it up the
>> mess recently so it solves the #2 issue.
>>
>> As well, Daniel and Jason(jemalloc maintainer) requested it to Andrew
>> again recently and they said it would be great to have even though
>> it has swap dependency now so Andrew decided he will do that for v4.4.
>>
> 
> First, thanks very much for refreshing the patchset and reposting after a 
> series of changes have been periodically added to -mm, it makes it much 
> easier.
> 
> For tcmalloc, we can do some things in the allocator itself to increase 
> the amount of memory backed by thp.  Specifically, we can prefer to 
> release Spans to pageblocks that are already not backed by thp so there is 
> no additional split on each scavenge.  This is somewhat easy if all memory 
> is organized into hugepage-aligned pageblocks in the allocator itself.  
> Second, we can prefer to release Spans of longer length on each scavenge 
> so we can delay scavenging for as long as possible in a hope we can find 
> more pages to coalesce.  Third, we can discount refaulted released memory 
> from the scavenging period.
> 
> That significantly improves the amount of memory backed by thp for 
> tcmalloc.  The problem, however, is that tcmalloc uses MADV_DONTNEED to 
> release memory to the system and MADV_FREE wouldn't help at all in a 
> swapless environment.
> 
> To combat that, I've proposed a new MADV bit that simply caches the 
> ranges freed by the allocator per vma and places them on both a per-vma 
> and per-memcg list.  During reclaim, this list is iterated and ptes are 
> freed after thp split period to the normal directed reclaim.  Without 
> memory pressure, this backs 100% of the heap with thp with a relatively 
> lightweight kernel change (the majority is vma manipulation on split) and 
> a couple line change to tcmalloc.  When pulling memory from the returned 
> freelists, the memory that we have MADV_DONTNEED'd, we need to use another 
> MADV bit to remove it from this cache, so there is a second madvise(2) 
> syscall involved but the freeing call is much less expensive since there 
> is no pagetable walk without memory pressure or synchronous thp split.
> 
> I've been looking at MADV_FREE to see if there is common ground that could 
> be shared, but perhaps it's just easier to ask what your proposed strategy 
> is so that tcmalloc users, especially those in swapless environments, 
> would benefit from any of your work?

The current implementation requires swap because the kernel already has
robust infrastructure for swapping out anonymous memory when there's
memory pressure. The MADV_FREE implementation just has to hook in there
and cause pages to be dropped instead of swapped out. There's no reason
it couldn't be extended to work in swapless environments, but it will
take additional design and implementation work. As a stop-gap, I think
zram and friends will work fine as a form of swap for this.

It can definitely be improved to cooperate well with THP too. I've been
following the progress, and most of the problems seem to have been with
the THP and that's a very active area of development. Seems best to deal
with that after a simple, working implementation lands.

The best aspect of MADV_FREE is that it completely avoids page faults
when there's no memory pressure. Making use of the freed memory only
triggers page faults if the pages had to be dropped because the system
ran out of memory. It also avoids needing to zero the pages. The memory
can also still be freed at any time if there's memory pressure again
even if it's handed out as an allocation until it's actually touched.

The call to madvise still has significant overhead, but it's much
cheaper than MADV_DONTNEED. Allocators will be able to lean on the
kernel to make good decisions rather than implementing lazy freeing
entirely on their own. It should improve performance *and* behavior
under memory pressure since allocators can be more aggressive with it
than MADV_DONTNEED.

A nice future improvement would be landing MADV_FREE_UNDO feature to
allow an attempt to pin the pages in memory again. It would make this
work very well for implementing caches that are dropped under memory
pressure. Windows has this via MEM_RESET (essentially MADV_FREE) and
MEM_RESET_UNDO. Android has it for ashmem too (pinning/unpinning). I
think browser vendors would be very interested in it.

[toc] | [prev] | [next] | [standalone]


#1261161

FromMinchan Kim <minchan@kernel.org>
Date2015-11-03 03:30 +0100
Message-ID<qqzwd-4Xh-3@gated-at.bofh.it>
In reply to#1260084
On Sun, Nov 01, 2015 at 01:29:45AM -0500, Daniel Micay wrote:
> On 01/11/15 12:51 AM, David Rientjes wrote:
> > On Fri, 30 Oct 2015, Minchan Kim wrote:
> > 
> >> MADV_FREE is on linux-next so long time. The reason was two, I think.
> >>
> >> 1. MADV_FREE code on reclaim path was really mess.
> >>
> >> 2. Andrew really want to see voice of userland people who want to use
> >>    the syscall.
> >>
> >> A few month ago, Daniel Micay(jemalloc active contributor) requested me
> >> to make progress upstreaming but I was busy at that time so it took
> >> so long time for me to revist the code and finally, I clean it up the
> >> mess recently so it solves the #2 issue.
> >>
> >> As well, Daniel and Jason(jemalloc maintainer) requested it to Andrew
> >> again recently and they said it would be great to have even though
> >> it has swap dependency now so Andrew decided he will do that for v4.4.
> >>
> > 
> > First, thanks very much for refreshing the patchset and reposting after a 
> > series of changes have been periodically added to -mm, it makes it much 
> > easier.
> > 
> > For tcmalloc, we can do some things in the allocator itself to increase 
> > the amount of memory backed by thp.  Specifically, we can prefer to 
> > release Spans to pageblocks that are already not backed by thp so there is 
> > no additional split on each scavenge.  This is somewhat easy if all memory 
> > is organized into hugepage-aligned pageblocks in the allocator itself.  
> > Second, we can prefer to release Spans of longer length on each scavenge 
> > so we can delay scavenging for as long as possible in a hope we can find 
> > more pages to coalesce.  Third, we can discount refaulted released memory 
> > from the scavenging period.
> > 
> > That significantly improves the amount of memory backed by thp for 
> > tcmalloc.  The problem, however, is that tcmalloc uses MADV_DONTNEED to 
> > release memory to the system and MADV_FREE wouldn't help at all in a 
> > swapless environment.
> > 
> > To combat that, I've proposed a new MADV bit that simply caches the 
> > ranges freed by the allocator per vma and places them on both a per-vma 
> > and per-memcg list.  During reclaim, this list is iterated and ptes are 
> > freed after thp split period to the normal directed reclaim.  Without 
> > memory pressure, this backs 100% of the heap with thp with a relatively 
> > lightweight kernel change (the majority is vma manipulation on split) and 
> > a couple line change to tcmalloc.  When pulling memory from the returned 
> > freelists, the memory that we have MADV_DONTNEED'd, we need to use another 
> > MADV bit to remove it from this cache, so there is a second madvise(2) 
> > syscall involved but the freeing call is much less expensive since there 
> > is no pagetable walk without memory pressure or synchronous thp split.
> > 
> > I've been looking at MADV_FREE to see if there is common ground that could 
> > be shared, but perhaps it's just easier to ask what your proposed strategy 
> > is so that tcmalloc users, especially those in swapless environments, 
> > would benefit from any of your work?
> 
> The current implementation requires swap because the kernel already has
> robust infrastructure for swapping out anonymous memory when there's
> memory pressure. The MADV_FREE implementation just has to hook in there
> and cause pages to be dropped instead of swapped out. There's no reason
> it couldn't be extended to work in swapless environments, but it will
> take additional design and implementation work. As a stop-gap, I think

Yes, I have two ideas to support swapless system.

First one I sent a few month ago but didn't receive enough comment.
https://lkml.org/lkml/2015/2/24/71

Second one, we could add new LRU list which has just MADV_FREEed
hinted pages and VM can age them fairly with another LRU lists.
It might be better policy but it needs more amount of changes in MM
so I want to listen from userland people once they start to use
syscall.

> zram and friends will work fine as a form of swap for this.
> 
> It can definitely be improved to cooperate well with THP too. I've been
> following the progress, and most of the problems seem to have been with
> the THP and that's a very active area of development. Seems best to deal
> with that after a simple, working implementation lands.

I have already patch which splits THP page lazy where in reclaim path,
not syscall context. The patch itself is really simple but THP is
sometime very subtle and is changing heavily so I didn't want to make
noise this time. If anyone needs it really this time,
I am happy to send it.

> 
> The best aspect of MADV_FREE is that it completely avoids page faults
> when there's no memory pressure. Making use of the freed memory only
> triggers page faults if the pages had to be dropped because the system
> ran out of memory. It also avoids needing to zero the pages. The memory
> can also still be freed at any time if there's memory pressure again
> even if it's handed out as an allocation until it's actually touched.
> 
> The call to madvise still has significant overhead, but it's much
> cheaper than MADV_DONTNEED. Allocators will be able to lean on the
> kernel to make good decisions rather than implementing lazy freeing
> entirely on their own. It should improve performance *and* behavior
> under memory pressure since allocators can be more aggressive with it
> than MADV_DONTNEED.
> 
> A nice future improvement would be landing MADV_FREE_UNDO feature to
> allow an attempt to pin the pages in memory again. It would make this
> work very well for implementing caches that are dropped under memory
> pressure. Windows has this via MEM_RESET (essentially MADV_FREE) and
> MEM_RESET_UNDO. Android has it for ashmem too (pinning/unpinning). I
> think browser vendors would be very interested in it.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel


csiph-web