Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1259262 > unrolled thread
| Started by | Minchan Kim <minchan@kernel.org> |
|---|---|
| First post | 2015-10-30 08:10 +0100 |
| Last post | 2015-11-04 21:20 +0100 |
| Articles | 20 on this page of 21 — 7 participants |
Back to article view | Back to linux.kernel
[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 →
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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]
| From | Hugh Dickins <hughd@google.com> |
|---|---|
| Date | 2015-11-02 01:10 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 03:40 +0100 |
| Subject | Re: [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]
| From | David Miller <davem@davemloft.net> |
|---|---|
| Date | 2015-11-03 04:40 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 05:40 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 03:40 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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]
| From | Shaohua Li <shli@kernel.org> |
|---|---|
| Date | 2015-10-30 17:50 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 01:20 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2015-10-30 13:50 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 02:20 +0100 |
| Subject | Re: [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]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2015-11-04 09:30 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2015-10-30 13:30 +0100 |
| Subject | Re: [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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-11-03 02:00 +0100 |
| Subject | Re: [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]
| From | David Rientjes <rientjes@google.com> |
|---|---|
| Date | 2015-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]
| From | Daniel Micay <danielmicay@gmail.com> |
|---|---|
| Date | 2015-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]
| From | Minchan Kim <minchan@kernel.org> |
|---|---|
| Date | 2015-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