All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Ulrich Drepper <drepper@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jakub Jelinek <jakub@redhat.com>, Dave Jones <davej@redhat.com>
Subject: [PATCH] stub MADV_FREE implementation
Date: Mon, 07 May 2007 23:51:47 -0400	[thread overview]
Message-ID: <463FF3D3.9060007@redhat.com> (raw)
In-Reply-To: <463BC62C.3060605@yahoo.com.au>

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

Until we have better performance numbers on the lazy reclaim path,
we can just alias MADV_FREE to MADV_DONTNEED with this trivial
patch.

This way glibc can go ahead with the optimization on their side
and we can figure out the kernel side later.

Signed-off-by: Rik van Riel <riel@redhat.com>

---
When I get back from the Red Hat Summit (Saturday), I will run more
performance numbers with and without the lazy reclaiming of pages.

Nick Piggin wrote:
> Ulrich Drepper wrote:
>> Nick Piggin wrote:
>>
>>> What I found is that, on this system, MADV_FREE performance improvement
>>> was in the noise when you look at it on top of the MADV_DONTNEED glibc
>>> and down_read(mmap_sem) patch in sysbench.
>>
>>
>> I don't want to judge the numbers since I cannot but I want to make an
>> observations: even if in the SMP case MADV_FREE turns out to not be a
>> bigger boost then there is still the UP case to keep in mind where Rik
>> measured a significant speed-up.  As long as the SMP case isn't hurt
>> this is reaosn enough to use the patch.  With more and more cores on one
>> processor SMP systems are pushed evermore to the high-end side.  You'll
>> find many installations which today use SMP will be happy enough with
>> many-core UP machines.
> 
> OK, sure. I think we need more numbers though.
> 
> And even if this was a patch with _no_ possibility for regressions and it
> was a completely trivial one that improves performance in some cases...
> one big problem is that it uses another page flag.
> 
> I literally have about 4 or 5 new page flags I'd like to add today :) I
> can't of course, because we have very few spare ones left.
> 
>  From the MySQL numbers on this system, it seems like performance is in the
> noise, and MADV_DONTNEED makes the _vast_ majority of the improvement.
> This is also the case with Rik's benchmarks, and while he did see some
> improvement, I found the runs to be quite variable, so it would be ideal
> to get a larger sample.
> 
> And the fact that the poor behaviour of the old style malloc/free went
> unnoticed for so long indicates that it won't be the end of the world if
> we didn't merge MADV_FREE right now.
> 


-- 
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

[-- Attachment #2: stub-madv_free --]
[-- Type: text/plain, Size: 4878 bytes --]

 include/asm-alpha/mman.h   |    1 +
 include/asm-generic/mman.h |    1 +
 include/asm-mips/mman.h    |    1 +
 include/asm-parisc/mman.h  |    1 +
 include/asm-sparc/mman.h   |    2 --
 include/asm-sparc64/mman.h |    2 --
 include/asm-xtensa/mman.h  |    1 +
 mm/madvise.c               |    2 ++
 8 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/asm-alpha/mman.h b/include/asm-alpha/mman.h
index 90d7c35..d47b5a3 100644
--- a/include/asm-alpha/mman.h
+++ b/include/asm-alpha/mman.h
@@ -42,6 +42,7 @@ #define MADV_SEQUENTIAL	2		/* expect seq
 #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		/* don't need the pages or the data */
 
 /* common/generic parameters */
 #define MADV_REMOVE	9		/* remove these pages & resources */
diff --git a/include/asm-generic/mman.h b/include/asm-generic/mman.h
index 5e3dde2..34a9ff1 100644
--- a/include/asm-generic/mman.h
+++ b/include/asm-generic/mman.h
@@ -29,6 +29,7 @@ #define MADV_RANDOM	1		/* expect random 
 #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		/* don't need the pages or the data */
 
 /* common parameters: try to keep these consistent across architectures */
 #define MADV_REMOVE	9		/* remove these pages & resources */
diff --git a/include/asm-mips/mman.h b/include/asm-mips/mman.h
index e4d6f1f..68067ff 100644
--- a/include/asm-mips/mman.h
+++ b/include/asm-mips/mman.h
@@ -65,6 +65,7 @@ #define MADV_RANDOM	1		/* expect random 
 #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		/* don't need the pages or the data */
 
 /* common parameters: try to keep these consistent across architectures */
 #define MADV_REMOVE	9		/* remove these pages & resources */
diff --git a/include/asm-parisc/mman.h b/include/asm-parisc/mman.h
index defe752..347fbca 100644
--- a/include/asm-parisc/mman.h
+++ b/include/asm-parisc/mman.h
@@ -38,6 +38,7 @@ #define MADV_DONTNEED   4               
 #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		/* don't need the pages or the data */
 
 /* common/generic parameters */
 #define MADV_REMOVE	9		/* remove these pages & resources */
diff --git a/include/asm-sparc/mman.h b/include/asm-sparc/mman.h
index b7dc40b..5ec7106 100644
--- a/include/asm-sparc/mman.h
+++ b/include/asm-sparc/mman.h
@@ -33,8 +33,6 @@ #define MC_UNLOCK       3  /* Unlock pag
 #define MC_LOCKAS       5  /* Lock an entire address space of the calling process */
 #define MC_UNLOCKAS     6  /* Unlock entire address space of calling process */
 
-#define MADV_FREE	0x5		/* (Solaris) contents can be freed */
-
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
 #define arch_mmap_check	sparc_mmap_check
diff --git a/include/asm-sparc64/mman.h b/include/asm-sparc64/mman.h
index 8cc1860..03b05d5 100644
--- a/include/asm-sparc64/mman.h
+++ b/include/asm-sparc64/mman.h
@@ -33,8 +33,6 @@ #define MC_UNLOCK       3  /* Unlock pag
 #define MC_LOCKAS       5  /* Lock an entire address space of the calling process */
 #define MC_UNLOCKAS     6  /* Unlock entire address space of calling process */
 
-#define MADV_FREE	0x5		/* (Solaris) contents can be freed */
-
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__
 #define arch_mmap_check	sparc64_mmap_check
diff --git a/include/asm-xtensa/mman.h b/include/asm-xtensa/mman.h
index 9b92620..1345703 100644
--- a/include/asm-xtensa/mman.h
+++ b/include/asm-xtensa/mman.h
@@ -72,6 +72,7 @@ #define MADV_RANDOM	1		/* expect random 
 #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		/* don't need the pages or the data */
 
 /* 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 e75096b..ad067f2 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -22,6 +22,7 @@ static int madvise_need_mmap_write(int b
 	case MADV_REMOVE:
 	case MADV_WILLNEED:
 	case MADV_DONTNEED:
+	case MADV_FREE:
 		return 0;
 	default:
 		/* be safe, default to 1. list exceptions explicitly */
@@ -234,6 +235,7 @@ madvise_vma(struct vm_area_struct *vma, 
 		break;
 
 	case MADV_DONTNEED:
+	case MADV_FREE:
 		error = madvise_dontneed(vma, prev, start, end);
 		break;
 

  parent reply	other threads:[~2007-05-08  3:52 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-28  4:43 [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory Rik van Riel
2007-05-04 10:53 ` Nick Piggin
2007-05-04 10:53   ` Nick Piggin
2007-05-04 11:58   ` Rik van Riel
2007-05-04 11:58     ` Rik van Riel
2007-05-04 23:49     ` Nick Piggin
2007-05-04 23:49       ` Nick Piggin
2007-05-04 16:04   ` Ulrich Drepper
2007-05-04 23:47     ` Nick Piggin
2007-05-04 23:47       ` Nick Piggin
2007-05-05  0:10       ` Ulrich Drepper
2007-05-06 22:43       ` Rik van Riel
2007-05-06 22:43         ` Rik van Riel
2007-05-07  2:42         ` Ulrich Drepper
2007-05-07  2:42           ` Ulrich Drepper
2007-05-07  4:56           ` Rik van Riel
2007-05-07  4:56             ` Rik van Riel
2007-05-07  4:53             ` Ulrich Drepper
2007-05-07  4:53               ` Ulrich Drepper
2007-05-07 16:51               ` Rik van Riel
2007-05-07 16:51                 ` Rik van Riel
2007-05-08  6:12         ` Nick Piggin
2007-05-08  6:12           ` Nick Piggin
2007-05-08 14:59           ` Rik van Riel
2007-05-08 14:59             ` Rik van Riel
2007-05-08 23:23             ` Nick Piggin
2007-05-08 23:23               ` Nick Piggin
2007-05-08 18:35           ` Jakub Jelinek
2007-05-08 18:35             ` Jakub Jelinek
2007-05-08 23:43             ` Nick Piggin
2007-05-08 23:43               ` Nick Piggin
2007-05-08  3:51       ` Rik van Riel [this message]
2007-05-08 23:05         ` [PATCH] stub MADV_FREE implementation Andrew Morton
2007-05-08 23:05           ` Andrew Morton
2007-05-09 17:15           ` Ulrich Drepper
2007-05-09 17:15             ` Ulrich Drepper
2007-05-09 16:38     ` [PATCH] MM: implement MADV_FREE lazy freeing of anonymous memory Hugh Dickins
2007-05-09 16:38       ` Hugh Dickins
2007-05-29 16:59   ` Rik van Riel
2007-05-29 16:59     ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=463FF3D3.9060007@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.