* [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-16 9:00 [PATCH 0/3] make mapped executable pages the first class citizen Wu Fengguang
@ 2009-05-16 9:00 ` Wu Fengguang
2009-05-16 13:17 ` Johannes Weiner
` (3 more replies)
2009-05-16 9:00 ` [PATCH 2/3] vmscan: make mapped executable pages the first class citizen Wu Fengguang
` (2 subsequent siblings)
3 siblings, 4 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-16 9:00 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Minchan Kim, Johannes Weiner, Peter Zijlstra, Wu Fengguang,
Christoph Lameter, KOSAKI Motohiro, riel@redhat.com,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
[-- Attachment #1: mm-vmscan-report-vm_flags-in-page_referenced.patch --]
[-- Type: text/plain, Size: 6144 bytes --]
Collect vma->vm_flags of the VMAs that actually referenced the page.
This is preparing for more informed reclaim heuristics,
eg. to protect executable file pages more aggressively.
For now only the VM_EXEC bit will be used by the caller.
CC: Minchan Kim <minchan.kim@gmail.com>
CC: Johannes Weiner <hannes@cmpxchg.org>
CC: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
include/linux/rmap.h | 5 +++--
mm/rmap.c | 37 ++++++++++++++++++++++++++-----------
mm/vmscan.c | 7 +++++--
3 files changed, 34 insertions(+), 15 deletions(-)
--- linux.orig/include/linux/rmap.h
+++ linux/include/linux/rmap.h
@@ -83,7 +83,8 @@ static inline void page_dup_rmap(struct
/*
* Called from mm/vmscan.c to handle paging out
*/
-int page_referenced(struct page *, int is_locked, struct mem_cgroup *cnt);
+int page_referenced(struct page *, int is_locked,
+ struct mem_cgroup *cnt, unsigned long *vm_flags);
int try_to_unmap(struct page *, int ignore_refs);
/*
@@ -128,7 +129,7 @@ int page_wrprotect(struct page *page, in
#define anon_vma_prepare(vma) (0)
#define anon_vma_link(vma) do {} while (0)
-#define page_referenced(page,l,cnt) TestClearPageReferenced(page)
+#define page_referenced(page, locked, cnt, flags) TestClearPageReferenced(page)
#define try_to_unmap(page, refs) SWAP_FAIL
static inline int page_mkclean(struct page *page)
--- linux.orig/mm/rmap.c
+++ linux/mm/rmap.c
@@ -333,7 +333,9 @@ static int page_mapped_in_vma(struct pag
* repeatedly from either page_referenced_anon or page_referenced_file.
*/
static int page_referenced_one(struct page *page,
- struct vm_area_struct *vma, unsigned int *mapcount)
+ struct vm_area_struct *vma,
+ unsigned int *mapcount,
+ unsigned long *vm_flags)
{
struct mm_struct *mm = vma->vm_mm;
unsigned long address;
@@ -381,11 +383,14 @@ out_unmap:
(*mapcount)--;
pte_unmap_unlock(pte, ptl);
out:
+ if (referenced)
+ *vm_flags |= vma->vm_flags;
return referenced;
}
static int page_referenced_anon(struct page *page,
- struct mem_cgroup *mem_cont)
+ struct mem_cgroup *mem_cont,
+ unsigned long *vm_flags)
{
unsigned int mapcount;
struct anon_vma *anon_vma;
@@ -405,7 +410,8 @@ static int page_referenced_anon(struct p
*/
if (mem_cont && !mm_match_cgroup(vma->vm_mm, mem_cont))
continue;
- referenced += page_referenced_one(page, vma, &mapcount);
+ referenced += page_referenced_one(page, vma,
+ &mapcount, vm_flags);
if (!mapcount)
break;
}
@@ -418,6 +424,7 @@ static int page_referenced_anon(struct p
* page_referenced_file - referenced check for object-based rmap
* @page: the page we're checking references on.
* @mem_cont: target memory controller
+ * @vm_flags: collect encountered vma->vm_flags
*
* For an object-based mapped page, find all the places it is mapped and
* check/clear the referenced flag. This is done by following the page->mapping
@@ -427,7 +434,8 @@ static int page_referenced_anon(struct p
* This function is only called from page_referenced for object-based pages.
*/
static int page_referenced_file(struct page *page,
- struct mem_cgroup *mem_cont)
+ struct mem_cgroup *mem_cont,
+ unsigned long *vm_flags)
{
unsigned int mapcount;
struct address_space *mapping = page->mapping;
@@ -467,7 +475,8 @@ static int page_referenced_file(struct p
*/
if (mem_cont && !mm_match_cgroup(vma->vm_mm, mem_cont))
continue;
- referenced += page_referenced_one(page, vma, &mapcount);
+ referenced += page_referenced_one(page, vma,
+ &mapcount, vm_flags);
if (!mapcount)
break;
}
@@ -481,29 +490,35 @@ static int page_referenced_file(struct p
* @page: the page to test
* @is_locked: caller holds lock on the page
* @mem_cont: target memory controller
+ * @vm_flags: collect encountered vma->vm_flags
*
* Quick test_and_clear_referenced for all mappings to a page,
* returns the number of ptes which referenced the page.
*/
-int page_referenced(struct page *page, int is_locked,
- struct mem_cgroup *mem_cont)
+int page_referenced(struct page *page,
+ int is_locked,
+ struct mem_cgroup *mem_cont,
+ unsigned long *vm_flags)
{
int referenced = 0;
if (TestClearPageReferenced(page))
referenced++;
+ *vm_flags = 0;
if (page_mapped(page) && page->mapping) {
if (PageAnon(page))
- referenced += page_referenced_anon(page, mem_cont);
+ referenced += page_referenced_anon(page, mem_cont,
+ vm_flags);
else if (is_locked)
- referenced += page_referenced_file(page, mem_cont);
+ referenced += page_referenced_file(page, mem_cont,
+ vm_flags);
else if (!trylock_page(page))
referenced++;
else {
if (page->mapping)
- referenced +=
- page_referenced_file(page, mem_cont);
+ referenced += page_referenced_file(page,
+ mem_cont, vm_flags);
unlock_page(page);
}
}
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -598,6 +598,7 @@ static unsigned long shrink_page_list(st
struct pagevec freed_pvec;
int pgactivate = 0;
unsigned long nr_reclaimed = 0;
+ unsigned long vm_flags;
cond_resched();
@@ -648,7 +649,8 @@ static unsigned long shrink_page_list(st
goto keep_locked;
}
- referenced = page_referenced(page, 1, sc->mem_cgroup);
+ referenced = page_referenced(page, 1,
+ sc->mem_cgroup, &vm_flags);
/* In active use or really unfreeable? Activate it. */
if (sc->order <= PAGE_ALLOC_COSTLY_ORDER &&
referenced && page_mapping_inuse(page))
@@ -1229,6 +1231,7 @@ static void shrink_active_list(unsigned
{
unsigned long pgmoved;
unsigned long pgscanned;
+ unsigned long vm_flags;
LIST_HEAD(l_hold); /* The pages which were snipped off */
LIST_HEAD(l_inactive);
struct page *page;
@@ -1269,7 +1272,7 @@ static void shrink_active_list(unsigned
/* page_referenced clears PageReferenced */
if (page_mapping_inuse(page) &&
- page_referenced(page, 0, sc->mem_cgroup))
+ page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
pgmoved++;
list_add(&page->lru, &l_inactive);
--
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
@ 2009-05-16 13:17 ` Johannes Weiner
2009-05-16 13:37 ` Rik van Riel
` (2 subsequent siblings)
3 siblings, 0 replies; 69+ messages in thread
From: Johannes Weiner @ 2009-05-16 13:17 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Minchan Kim, Peter Zijlstra,
Christoph Lameter, KOSAKI Motohiro, riel@redhat.com,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
On Sat, May 16, 2009 at 05:00:06PM +0800, Wu Fengguang wrote:
> Collect vma->vm_flags of the VMAs that actually referenced the page.
>
> This is preparing for more informed reclaim heuristics,
> eg. to protect executable file pages more aggressively.
> For now only the VM_EXEC bit will be used by the caller.
>
> CC: Minchan Kim <minchan.kim@gmail.com>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
2009-05-16 13:17 ` Johannes Weiner
@ 2009-05-16 13:37 ` Rik van Riel
2009-05-17 0:35 ` Minchan Kim
2009-05-17 1:36 ` Minchan Kim
3 siblings, 0 replies; 69+ messages in thread
From: Rik van Riel @ 2009-05-16 13:37 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Minchan Kim, Johannes Weiner, Peter Zijlstra,
Christoph Lameter, KOSAKI Motohiro, tytso@mit.edu,
linux-mm@kvack.org, elladan@eskimo.com, npiggin@suse.de
Wu Fengguang wrote:
> Collect vma->vm_flags of the VMAs that actually referenced the page.
>
> This is preparing for more informed reclaim heuristics,
> eg. to protect executable file pages more aggressively.
> For now only the VM_EXEC bit will be used by the caller.
>
> CC: Minchan Kim <minchan.kim@gmail.com>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
--
All rights reversed.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
2009-05-16 13:17 ` Johannes Weiner
2009-05-16 13:37 ` Rik van Riel
@ 2009-05-17 0:35 ` Minchan Kim
2009-05-17 1:36 ` Minchan Kim
3 siblings, 0 replies; 69+ messages in thread
From: Minchan Kim @ 2009-05-17 0:35 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Johannes Weiner, Peter Zijlstra,
Christoph Lameter, KOSAKI Motohiro, riel@redhat.com,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
On Sat, May 16, 2009 at 6:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> Collect vma->vm_flags of the VMAs that actually referenced the page.
>
> This is preparing for more informed reclaim heuristics,
> eg. to protect executable file pages more aggressively.
> For now only the VM_EXEC bit will be used by the caller.
>
> CC: Minchan Kim <minchan.kim@gmail.com>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
` (2 preceding siblings ...)
2009-05-17 0:35 ` Minchan Kim
@ 2009-05-17 1:36 ` Minchan Kim
2009-05-17 1:58 ` Wu Fengguang
3 siblings, 1 reply; 69+ messages in thread
From: Minchan Kim @ 2009-05-17 1:36 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Johannes Weiner, Peter Zijlstra,
Christoph Lameter, KOSAKI Motohiro, riel@redhat.com,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
On Sat, May 16, 2009 at 6:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> Collect vma->vm_flags of the VMAs that actually referenced the page.
>
> This is preparing for more informed reclaim heuristics,
> eg. to protect executable file pages more aggressively.
> For now only the VM_EXEC bit will be used by the caller.
>
> CC: Minchan Kim <minchan.kim@gmail.com>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
> include/linux/rmap.h | 5 +++--
> mm/rmap.c | 37 ++++++++++++++++++++++++++-----------
> mm/vmscan.c | 7 +++++--
> 3 files changed, 34 insertions(+), 15 deletions(-)
>
> --- linux.orig/include/linux/rmap.h
> +++ linux/include/linux/rmap.h
> @@ -83,7 +83,8 @@ static inline void page_dup_rmap(struct
> /*
> * Called from mm/vmscan.c to handle paging out
> */
> -int page_referenced(struct page *, int is_locked, struct mem_cgroup *cnt);
> +int page_referenced(struct page *, int is_locked,
> + struct mem_cgroup *cnt, unsigned long *vm_flags);
> int try_to_unmap(struct page *, int ignore_refs);
>
> /*
> @@ -128,7 +129,7 @@ int page_wrprotect(struct page *page, in
> #define anon_vma_prepare(vma) (0)
> #define anon_vma_link(vma) do {} while (0)
>
> -#define page_referenced(page,l,cnt) TestClearPageReferenced(page)
> +#define page_referenced(page, locked, cnt, flags) TestClearPageReferenced(page)
> #define try_to_unmap(page, refs) SWAP_FAIL
>
> static inline int page_mkclean(struct page *page)
> --- linux.orig/mm/rmap.c
> +++ linux/mm/rmap.c
> @@ -333,7 +333,9 @@ static int page_mapped_in_vma(struct pag
> * repeatedly from either page_referenced_anon or page_referenced_file.
> */
> static int page_referenced_one(struct page *page,
> - struct vm_area_struct *vma, unsigned int *mapcount)
> + struct vm_area_struct *vma,
> + unsigned int *mapcount,
> + unsigned long *vm_flags)
> {
> struct mm_struct *mm = vma->vm_mm;
> unsigned long address;
> @@ -381,11 +383,14 @@ out_unmap:
> (*mapcount)--;
> pte_unmap_unlock(pte, ptl);
> out:
> + if (referenced)
> + *vm_flags |= vma->vm_flags;
> return referenced;
> }
>
> static int page_referenced_anon(struct page *page,
> - struct mem_cgroup *mem_cont)
> + struct mem_cgroup *mem_cont,
> + unsigned long *vm_flags)
> {
> unsigned int mapcount;
> struct anon_vma *anon_vma;
> @@ -405,7 +410,8 @@ static int page_referenced_anon(struct p
> */
> if (mem_cont && !mm_match_cgroup(vma->vm_mm, mem_cont))
> continue;
> - referenced += page_referenced_one(page, vma, &mapcount);
> + referenced += page_referenced_one(page, vma,
> + &mapcount, vm_flags);
> if (!mapcount)
> break;
> }
> @@ -418,6 +424,7 @@ static int page_referenced_anon(struct p
> * page_referenced_file - referenced check for object-based rmap
> * @page: the page we're checking references on.
> * @mem_cont: target memory controller
> + * @vm_flags: collect encountered vma->vm_flags
I missed this.
To clarify, how about ?
collect encountered vma->vm_flags among vma which referenced the page
--
Kinds regards,
Minchan Kim
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 1/3] vmscan: report vm_flags in page_referenced()
2009-05-17 1:36 ` Minchan Kim
@ 2009-05-17 1:58 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-17 1:58 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, LKML, Johannes Weiner, Peter Zijlstra,
Christoph Lameter, KOSAKI Motohiro, riel@redhat.com,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
On Sun, May 17, 2009 at 09:36:44AM +0800, Minchan Kim wrote:
> On Sat, May 16, 2009 at 6:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > Collect vma->vm_flags of the VMAs that actually referenced the page.
> >
> > This is preparing for more informed reclaim heuristics,
> > eg. to protect executable file pages more aggressively.
> > For now only the VM_EXEC bit will be used by the caller.
> >
> > CC: Minchan Kim <minchan.kim@gmail.com>
> > CC: Johannes Weiner <hannes@cmpxchg.org>
> > CC: Peter Zijlstra <peterz@infradead.org>
> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > ---
> > include/linux/rmap.h | 5 +++--
> > mm/rmap.c | 37 ++++++++++++++++++++++++++-----------
> > mm/vmscan.c | 7 +++++--
> > 3 files changed, 34 insertions(+), 15 deletions(-)
> >
> > --- linux.orig/include/linux/rmap.h
> > +++ linux/include/linux/rmap.h
> > @@ -83,7 +83,8 @@ static inline void page_dup_rmap(struct
> > /*
> > * Called from mm/vmscan.c to handle paging out
> > */
> > -int page_referenced(struct page *, int is_locked, struct mem_cgroup *cnt);
> > +int page_referenced(struct page *, int is_locked,
> > + struct mem_cgroup *cnt, unsigned long *vm_flags);
> > int try_to_unmap(struct page *, int ignore_refs);
> >
> > /*
> > @@ -128,7 +129,7 @@ int page_wrprotect(struct page *page, in
> > #define anon_vma_prepare(vma) (0)
> > #define anon_vma_link(vma) do {} while (0)
> >
> > -#define page_referenced(page,l,cnt) TestClearPageReferenced(page)
> > +#define page_referenced(page, locked, cnt, flags) TestClearPageReferenced(page)
> > #define try_to_unmap(page, refs) SWAP_FAIL
> >
> > static inline int page_mkclean(struct page *page)
> > --- linux.orig/mm/rmap.c
> > +++ linux/mm/rmap.c
> > @@ -333,7 +333,9 @@ static int page_mapped_in_vma(struct pag
> > * repeatedly from either page_referenced_anon or page_referenced_file.
> > */
> > static int page_referenced_one(struct page *page,
> > - struct vm_area_struct *vma, unsigned int *mapcount)
> > + struct vm_area_struct *vma,
> > + unsigned int *mapcount,
> > + unsigned long *vm_flags)
> > {
> > struct mm_struct *mm = vma->vm_mm;
> > unsigned long address;
> > @@ -381,11 +383,14 @@ out_unmap:
> > (*mapcount)--;
> > pte_unmap_unlock(pte, ptl);
> > out:
> > + if (referenced)
> > + *vm_flags |= vma->vm_flags;
> > return referenced;
> > }
> >
> > static int page_referenced_anon(struct page *page,
> > - struct mem_cgroup *mem_cont)
> > + struct mem_cgroup *mem_cont,
> > + unsigned long *vm_flags)
> > {
> > unsigned int mapcount;
> > struct anon_vma *anon_vma;
> > @@ -405,7 +410,8 @@ static int page_referenced_anon(struct p
> > */
> > if (mem_cont && !mm_match_cgroup(vma->vm_mm, mem_cont))
> > continue;
> > - referenced += page_referenced_one(page, vma, &mapcount);
> > + referenced += page_referenced_one(page, vma,
> > + &mapcount, vm_flags);
> > if (!mapcount)
> > break;
> > }
> > @@ -418,6 +424,7 @@ static int page_referenced_anon(struct p
> > * page_referenced_file - referenced check for object-based rmap
> > * @page: the page we're checking references on.
> > * @mem_cont: target memory controller
> > + * @vm_flags: collect encountered vma->vm_flags
>
> I missed this.
> To clarify, how about ?
> collect encountered vma->vm_flags among vma which referenced the page
Good catch! I'll resubmit the whole patchset :)
[ In fact I was thinking about changing those comments - and then
forgot it over night. I should really put some notepad around me. ]
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:00 [PATCH 0/3] make mapped executable pages the first class citizen Wu Fengguang
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
@ 2009-05-16 9:00 ` Wu Fengguang
2009-05-16 9:28 ` Wu Fengguang
2009-05-19 6:39 ` Pekka Enberg
2009-05-16 9:00 ` [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list() Wu Fengguang
2009-05-16 14:56 ` [PATCH 0/3] make mapped executable pages the first class citizen Peter Zijlstra
3 siblings, 2 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-16 9:00 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Elladan, Nick Piggin, Johannes Weiner, Christoph Lameter,
KOSAKI Motohiro, Peter Zijlstra, Rik van Riel, Wu Fengguang,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
[-- Attachment #1: mm-vmscan-protect-exec-referenced.patch --]
[-- Type: text/plain, Size: 7387 bytes --]
Protect referenced PROT_EXEC mapped pages from being deactivated.
PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
currently running executables and their linked libraries, they shall really be
cached aggressively to provide good user experiences.
Thanks to Johannes Weiner for the advice to reuse the VMA walk in
page_referenced() to get the PROT_EXEC bit.
[more details]
( The consequences of this patch will have to be discussed together with
Rik van Riel's recent patch "vmscan: evict use-once pages first". )
( Some of the good points and insights are taken into this changelog.
Thanks to all the involved people for the great LKML discussions. )
the problem
-----------
For a typical desktop, the most precious working set is composed of
*actively accessed*
(1) memory mapped executables
(2) and their anonymous pages
(3) and other files
(4) and the dcache/icache/.. slabs
while the least important data are
(5) infrequently used or use-once files
For a typical desktop, one major problem is busty and large amount of (5)
use-once files flushing out the working set.
Inside the working set, (4) dcache/icache have already been too sticky ;-)
So we only have to care (2) anonymous and (1)(3) file pages.
anonymous pages
---------------
Anonymous pages are effectively immune to the streaming IO attack, because we
now have separate file/anon LRU lists. When the use-once files crowd into the
file LRU, the list's "quality" is significantly lowered. Therefore the scan
balance policy in get_scan_ratio() will choose to scan the (low quality) file
LRU much more frequently than the anon LRU.
file pages
----------
Rik proposed to *not* scan the active file LRU when the inactive list grows
larger than active list. This guarantees that when there are use-once streaming
IO, and the working set is not too large(so that active_size < inactive_size),
the active file LRU will *not* be scanned at all. So the not-too-large working
set can be well protected.
But there are also situations where the file working set is a bit large so that
(active_size >= inactive_size), or the streaming IOs are not purely use-once.
In these cases, the active list will be scanned slowly. Because the current
shrink_active_list() policy is to deactivate active pages regardless of their
referenced bits. The deactivated pages become susceptible to the streaming IO
attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
the deactivated pages don't have enough time to get re-referenced. Because a
user tend to switch between windows in intervals from seconds to minutes.
This patch holds mapped executable pages in the active list as long as they
are referenced during each full scan of the active list. Because the active
list is normally scanned much slower, they get longer grace time (eg. 100s)
for further references, which better matches the pace of user operations.
Therefore this patch greatly prolongs the in-cache time of executable code,
when there are moderate memory pressures.
before patch: guaranteed to be cached if reference intervals < I
after patch: guaranteed to be cached if reference intervals < I+A
(except when randomly reclaimed by the lumpy reclaim)
where
A = time to fully scan the active file LRU
I = time to fully scan the inactive file LRU
Note that normally A >> I.
side effects
------------
This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
but in a much smaller and well targeted scope.
One may worry about some one to abuse the PROT_EXEC heuristic. But as
Andrew Morton stated, there are other tricks to getting that sort of boost.
Another concern is the PROT_EXEC mapped pages growing large in rare cases,
and therefore hurting reclaim efficiency. But a sane application targeted for
large audience will never use PROT_EXEC for data mappings. If some home made
application tries to abuse that bit, it shall be aware of the consequences.
If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
CC: Elladan <elladan@eskimo.com>
CC: Nick Piggin <npiggin@suse.de>
CC: Johannes Weiner <hannes@cmpxchg.org>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/vmscan.c | 46 +++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 41 insertions(+), 5 deletions(-)
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1233,6 +1233,7 @@ static void shrink_active_list(unsigned
unsigned long pgscanned;
unsigned long vm_flags;
LIST_HEAD(l_hold); /* The pages which were snipped off */
+ LIST_HEAD(l_active);
LIST_HEAD(l_inactive);
struct page *page;
struct pagevec pvec;
@@ -1272,28 +1273,40 @@ static void shrink_active_list(unsigned
/* page_referenced clears PageReferenced */
if (page_mapping_inuse(page) &&
- page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
+ page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
pgmoved++;
+ /*
+ * Identify referenced, file-backed active pages and
+ * give them one more trip around the active list. So
+ * that executable code get better chances to stay in
+ * memory under moderate memory pressure. Anon pages
+ * are ignored, since JVM can create lots of anon
+ * VM_EXEC pages.
+ */
+ if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
+ list_add(&page->lru, &l_active);
+ continue;
+ }
+ }
list_add(&page->lru, &l_inactive);
}
/*
- * Move the pages to the [file or anon] inactive list.
+ * Move pages back to the lru list.
*/
pagevec_init(&pvec, 1);
- lru = LRU_BASE + file * LRU_FILE;
spin_lock_irq(&zone->lru_lock);
/*
- * Count referenced pages from currently used mappings as
- * rotated, even though they are moved to the inactive list.
+ * Count referenced pages from currently used mappings as rotated.
* This helps balance scan pressure between file and anonymous
* pages in get_scan_ratio.
*/
reclaim_stat->recent_rotated[!!file] += pgmoved;
pgmoved = 0; /* count pages moved to inactive list */
+ lru = LRU_BASE + file * LRU_FILE;
while (!list_empty(&l_inactive)) {
page = lru_to_page(&l_inactive);
prefetchw_prev_lru_page(page, &l_inactive, flags);
@@ -1316,6 +1329,29 @@ static void shrink_active_list(unsigned
__mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
__count_zone_vm_events(PGREFILL, zone, pgscanned);
__count_vm_events(PGDEACTIVATE, pgmoved);
+
+ pgmoved = 0; /* count pages moved back to active list */
+ lru = LRU_ACTIVE + file * LRU_FILE;
+ while (!list_empty(&l_active)) {
+ page = lru_to_page(&l_active);
+ prefetchw_prev_lru_page(page, &l_active, flags);
+ VM_BUG_ON(PageLRU(page));
+ SetPageLRU(page);
+ VM_BUG_ON(!PageActive(page));
+
+ list_move(&page->lru, &zone->lru[lru].list);
+ mem_cgroup_add_lru_list(page, lru);
+ pgmoved++;
+ if (!pagevec_add(&pvec, page)) {
+ spin_unlock_irq(&zone->lru_lock);
+ if (buffer_heads_over_limit)
+ pagevec_strip(&pvec);
+ __pagevec_release(&pvec);
+ spin_lock_irq(&zone->lru_lock);
+ }
+ }
+ __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+
spin_unlock_irq(&zone->lru_lock);
if (buffer_heads_over_limit)
pagevec_strip(&pvec);
--
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:00 ` [PATCH 2/3] vmscan: make mapped executable pages the first class citizen Wu Fengguang
@ 2009-05-16 9:28 ` Wu Fengguang
2009-05-16 13:20 ` Johannes Weiner
` (2 more replies)
2009-05-19 6:39 ` Pekka Enberg
1 sibling, 3 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-16 9:28 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Elladan, Nick Piggin, Johannes Weiner, Christoph Lameter,
KOSAKI Motohiro, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
[trivial update on comment text, according to Rik's comment]
--
vmscan: make mapped executable pages the first class citizen
Protect referenced PROT_EXEC mapped pages from being deactivated.
PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
currently running executables and their linked libraries, they shall really be
cached aggressively to provide good user experiences.
Thanks to Johannes Weiner for the advice to reuse the VMA walk in
page_referenced() to get the PROT_EXEC bit.
[more details]
( The consequences of this patch will have to be discussed together with
Rik van Riel's recent patch "vmscan: evict use-once pages first". )
( Some of the good points and insights are taken into this changelog.
Thanks to all the involved people for the great LKML discussions. )
the problem
-----------
For a typical desktop, the most precious working set is composed of
*actively accessed*
(1) memory mapped executables
(2) and their anonymous pages
(3) and other files
(4) and the dcache/icache/.. slabs
while the least important data are
(5) infrequently used or use-once files
For a typical desktop, one major problem is busty and large amount of (5)
use-once files flushing out the working set.
Inside the working set, (4) dcache/icache have already been too sticky ;-)
So we only have to care (2) anonymous and (1)(3) file pages.
anonymous pages
---------------
Anonymous pages are effectively immune to the streaming IO attack, because we
now have separate file/anon LRU lists. When the use-once files crowd into the
file LRU, the list's "quality" is significantly lowered. Therefore the scan
balance policy in get_scan_ratio() will choose to scan the (low quality) file
LRU much more frequently than the anon LRU.
file pages
----------
Rik proposed to *not* scan the active file LRU when the inactive list grows
larger than active list. This guarantees that when there are use-once streaming
IO, and the working set is not too large(so that active_size < inactive_size),
the active file LRU will *not* be scanned at all. So the not-too-large working
set can be well protected.
But there are also situations where the file working set is a bit large so that
(active_size >= inactive_size), or the streaming IOs are not purely use-once.
In these cases, the active list will be scanned slowly. Because the current
shrink_active_list() policy is to deactivate active pages regardless of their
referenced bits. The deactivated pages become susceptible to the streaming IO
attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
the deactivated pages don't have enough time to get re-referenced. Because a
user tend to switch between windows in intervals from seconds to minutes.
This patch holds mapped executable pages in the active list as long as they
are referenced during each full scan of the active list. Because the active
list is normally scanned much slower, they get longer grace time (eg. 100s)
for further references, which better matches the pace of user operations.
Therefore this patch greatly prolongs the in-cache time of executable code,
when there are moderate memory pressures.
before patch: guaranteed to be cached if reference intervals < I
after patch: guaranteed to be cached if reference intervals < I+A
(except when randomly reclaimed by the lumpy reclaim)
where
A = time to fully scan the active file LRU
I = time to fully scan the inactive file LRU
Note that normally A >> I.
side effects
------------
This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
but in a much smaller and well targeted scope.
One may worry about some one to abuse the PROT_EXEC heuristic. But as
Andrew Morton stated, there are other tricks to getting that sort of boost.
Another concern is the PROT_EXEC mapped pages growing large in rare cases,
and therefore hurting reclaim efficiency. But a sane application targeted for
large audience will never use PROT_EXEC for data mappings. If some home made
application tries to abuse that bit, it shall be aware of the consequences.
If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
CC: Elladan <elladan@eskimo.com>
CC: Nick Piggin <npiggin@suse.de>
CC: Johannes Weiner <hannes@cmpxchg.org>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/vmscan.c | 51 +++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 44 insertions(+), 7 deletions(-)
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1233,6 +1233,7 @@ static void shrink_active_list(unsigned
unsigned long pgscanned;
unsigned long vm_flags;
LIST_HEAD(l_hold); /* The pages which were snipped off */
+ LIST_HEAD(l_active);
LIST_HEAD(l_inactive);
struct page *page;
struct pagevec pvec;
@@ -1272,28 +1273,41 @@ static void shrink_active_list(unsigned
/* page_referenced clears PageReferenced */
if (page_mapping_inuse(page) &&
- page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
+ page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
pgmoved++;
+ /*
+ * Identify referenced, file-backed active pages and
+ * give them one more trip around the active list. So
+ * that executable code get better chances to stay in
+ * memory under moderate memory pressure. Anon pages
+ * are ignored, since JVM can create lots of anon
+ * VM_EXEC pages.
+ */
+ if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
+ list_add(&page->lru, &l_active);
+ continue;
+ }
+ }
list_add(&page->lru, &l_inactive);
}
/*
- * Move the pages to the [file or anon] inactive list.
+ * Move pages back to the lru list.
*/
pagevec_init(&pvec, 1);
- lru = LRU_BASE + file * LRU_FILE;
spin_lock_irq(&zone->lru_lock);
/*
- * Count referenced pages from currently used mappings as
- * rotated, even though they are moved to the inactive list.
- * This helps balance scan pressure between file and anonymous
- * pages in get_scan_ratio.
+ * Count referenced pages from currently used mappings as rotated,
+ * even though only some of them are actually re-activated. This
+ * helps balance scan pressure between file and anonymous pages in
+ * get_scan_ratio.
*/
reclaim_stat->recent_rotated[!!file] += pgmoved;
pgmoved = 0; /* count pages moved to inactive list */
+ lru = LRU_BASE + file * LRU_FILE;
while (!list_empty(&l_inactive)) {
page = lru_to_page(&l_inactive);
prefetchw_prev_lru_page(page, &l_inactive, flags);
@@ -1316,6 +1330,29 @@ static void shrink_active_list(unsigned
__mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
__count_zone_vm_events(PGREFILL, zone, pgscanned);
__count_vm_events(PGDEACTIVATE, pgmoved);
+
+ pgmoved = 0; /* count pages moved back to active list */
+ lru = LRU_ACTIVE + file * LRU_FILE;
+ while (!list_empty(&l_active)) {
+ page = lru_to_page(&l_active);
+ prefetchw_prev_lru_page(page, &l_active, flags);
+ VM_BUG_ON(PageLRU(page));
+ SetPageLRU(page);
+ VM_BUG_ON(!PageActive(page));
+
+ list_move(&page->lru, &zone->lru[lru].list);
+ mem_cgroup_add_lru_list(page, lru);
+ pgmoved++;
+ if (!pagevec_add(&pvec, page)) {
+ spin_unlock_irq(&zone->lru_lock);
+ if (buffer_heads_over_limit)
+ pagevec_strip(&pvec);
+ __pagevec_release(&pvec);
+ spin_lock_irq(&zone->lru_lock);
+ }
+ }
+ __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+
spin_unlock_irq(&zone->lru_lock);
if (buffer_heads_over_limit)
pagevec_strip(&pvec);
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:28 ` Wu Fengguang
@ 2009-05-16 13:20 ` Johannes Weiner
2009-05-17 0:38 ` Minchan Kim
2009-05-18 14:46 ` Christoph Lameter
2 siblings, 0 replies; 69+ messages in thread
From: Johannes Weiner @ 2009-05-16 13:20 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Elladan, Nick Piggin, Christoph Lameter,
KOSAKI Motohiro, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Sat, May 16, 2009 at 05:28:58PM +0800, Wu Fengguang wrote:
> [trivial update on comment text, according to Rik's comment]
>
> --
> vmscan: make mapped executable pages the first class citizen
>
> Protect referenced PROT_EXEC mapped pages from being deactivated.
>
> PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
> currently running executables and their linked libraries, they shall really be
> cached aggressively to provide good user experiences.
>
> Thanks to Johannes Weiner for the advice to reuse the VMA walk in
> page_referenced() to get the PROT_EXEC bit.
>
>
> [more details]
>
> ( The consequences of this patch will have to be discussed together with
> Rik van Riel's recent patch "vmscan: evict use-once pages first". )
>
> ( Some of the good points and insights are taken into this changelog.
> Thanks to all the involved people for the great LKML discussions. )
>
> the problem
> -----------
>
> For a typical desktop, the most precious working set is composed of
> *actively accessed*
> (1) memory mapped executables
> (2) and their anonymous pages
> (3) and other files
> (4) and the dcache/icache/.. slabs
> while the least important data are
> (5) infrequently used or use-once files
>
> For a typical desktop, one major problem is busty and large amount of (5)
> use-once files flushing out the working set.
>
> Inside the working set, (4) dcache/icache have already been too sticky ;-)
> So we only have to care (2) anonymous and (1)(3) file pages.
>
> anonymous pages
> ---------------
> Anonymous pages are effectively immune to the streaming IO attack, because we
> now have separate file/anon LRU lists. When the use-once files crowd into the
> file LRU, the list's "quality" is significantly lowered. Therefore the scan
> balance policy in get_scan_ratio() will choose to scan the (low quality) file
> LRU much more frequently than the anon LRU.
>
> file pages
> ----------
> Rik proposed to *not* scan the active file LRU when the inactive list grows
> larger than active list. This guarantees that when there are use-once streaming
> IO, and the working set is not too large(so that active_size < inactive_size),
> the active file LRU will *not* be scanned at all. So the not-too-large working
> set can be well protected.
>
> But there are also situations where the file working set is a bit large so that
> (active_size >= inactive_size), or the streaming IOs are not purely use-once.
> In these cases, the active list will be scanned slowly. Because the current
> shrink_active_list() policy is to deactivate active pages regardless of their
> referenced bits. The deactivated pages become susceptible to the streaming IO
> attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
> the deactivated pages don't have enough time to get re-referenced. Because a
> user tend to switch between windows in intervals from seconds to minutes.
>
> This patch holds mapped executable pages in the active list as long as they
> are referenced during each full scan of the active list. Because the active
> list is normally scanned much slower, they get longer grace time (eg. 100s)
> for further references, which better matches the pace of user operations.
>
> Therefore this patch greatly prolongs the in-cache time of executable code,
> when there are moderate memory pressures.
>
> before patch: guaranteed to be cached if reference intervals < I
> after patch: guaranteed to be cached if reference intervals < I+A
> (except when randomly reclaimed by the lumpy reclaim)
> where
> A = time to fully scan the active file LRU
> I = time to fully scan the inactive file LRU
>
> Note that normally A >> I.
>
> side effects
> ------------
>
> This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
> but in a much smaller and well targeted scope.
>
> One may worry about some one to abuse the PROT_EXEC heuristic. But as
> Andrew Morton stated, there are other tricks to getting that sort of boost.
>
> Another concern is the PROT_EXEC mapped pages growing large in rare cases,
> and therefore hurting reclaim efficiency. But a sane application targeted for
> large audience will never use PROT_EXEC for data mappings. If some home made
> application tries to abuse that bit, it shall be aware of the consequences.
> If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
>
> CC: Elladan <elladan@eskimo.com>
> CC: Nick Piggin <npiggin@suse.de>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Christoph Lameter <cl@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>
> Acked-by: Rik van Riel <riel@redhat.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:28 ` Wu Fengguang
2009-05-16 13:20 ` Johannes Weiner
@ 2009-05-17 0:38 ` Minchan Kim
2009-05-18 14:46 ` Christoph Lameter
2 siblings, 0 replies; 69+ messages in thread
From: Minchan Kim @ 2009-05-17 0:38 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Elladan, Nick Piggin, Johannes Weiner,
Christoph Lameter, KOSAKI Motohiro, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org
On Sat, May 16, 2009 at 6:28 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> [trivial update on comment text, according to Rik's comment]
>
> --
> vmscan: make mapped executable pages the first class citizen
>
> Protect referenced PROT_EXEC mapped pages from being deactivated.
>
> PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
> currently running executables and their linked libraries, they shall really be
> cached aggressively to provide good user experiences.
>
> Thanks to Johannes Weiner for the advice to reuse the VMA walk in
> page_referenced() to get the PROT_EXEC bit.
>
>
> [more details]
>
> ( The consequences of this patch will have to be discussed together with
> Rik van Riel's recent patch "vmscan: evict use-once pages first". )
>
> ( Some of the good points and insights are taken into this changelog.
> Thanks to all the involved people for the great LKML discussions. )
>
> the problem
> -----------
>
> For a typical desktop, the most precious working set is composed of
> *actively accessed*
> (1) memory mapped executables
> (2) and their anonymous pages
> (3) and other files
> (4) and the dcache/icache/.. slabs
> while the least important data are
> (5) infrequently used or use-once files
>
> For a typical desktop, one major problem is busty and large amount of (5)
> use-once files flushing out the working set.
>
> Inside the working set, (4) dcache/icache have already been too sticky ;-)
> So we only have to care (2) anonymous and (1)(3) file pages.
>
> anonymous pages
> ---------------
> Anonymous pages are effectively immune to the streaming IO attack, because we
> now have separate file/anon LRU lists. When the use-once files crowd into the
> file LRU, the list's "quality" is significantly lowered. Therefore the scan
> balance policy in get_scan_ratio() will choose to scan the (low quality) file
> LRU much more frequently than the anon LRU.
>
> file pages
> ----------
> Rik proposed to *not* scan the active file LRU when the inactive list grows
> larger than active list. This guarantees that when there are use-once streaming
> IO, and the working set is not too large(so that active_size < inactive_size),
> the active file LRU will *not* be scanned at all. So the not-too-large working
> set can be well protected.
>
> But there are also situations where the file working set is a bit large so that
> (active_size >= inactive_size), or the streaming IOs are not purely use-once.
> In these cases, the active list will be scanned slowly. Because the current
> shrink_active_list() policy is to deactivate active pages regardless of their
> referenced bits. The deactivated pages become susceptible to the streaming IO
> attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
> the deactivated pages don't have enough time to get re-referenced. Because a
> user tend to switch between windows in intervals from seconds to minutes.
>
> This patch holds mapped executable pages in the active list as long as they
> are referenced during each full scan of the active list. Because the active
> list is normally scanned much slower, they get longer grace time (eg. 100s)
> for further references, which better matches the pace of user operations.
>
> Therefore this patch greatly prolongs the in-cache time of executable code,
> when there are moderate memory pressures.
>
> before patch: guaranteed to be cached if reference intervals < I
> after patch: guaranteed to be cached if reference intervals < I+A
> (except when randomly reclaimed by the lumpy reclaim)
> where
> A = time to fully scan the active file LRU
> I = time to fully scan the inactive file LRU
>
> Note that normally A >> I.
>
> side effects
> ------------
>
> This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
> but in a much smaller and well targeted scope.
>
> One may worry about some one to abuse the PROT_EXEC heuristic. But as
> Andrew Morton stated, there are other tricks to getting that sort of boost.
>
> Another concern is the PROT_EXEC mapped pages growing large in rare cases,
> and therefore hurting reclaim efficiency. But a sane application targeted for
> large audience will never use PROT_EXEC for data mappings. If some home made
> application tries to abuse that bit, it shall be aware of the consequences.
> If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
>
> CC: Elladan <elladan@eskimo.com>
> CC: Nick Piggin <npiggin@suse.de>
> CC: Johannes Weiner <hannes@cmpxchg.org>
> CC: Christoph Lameter <cl@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>
> Acked-by: Rik van Riel <riel@redhat.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:28 ` Wu Fengguang
2009-05-16 13:20 ` Johannes Weiner
2009-05-17 0:38 ` Minchan Kim
@ 2009-05-18 14:46 ` Christoph Lameter
2009-05-19 3:27 ` Wu Fengguang
2 siblings, 1 reply; 69+ messages in thread
From: Christoph Lameter @ 2009-05-18 14:46 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Elladan, Nick Piggin, Johannes Weiner,
KOSAKI Motohiro, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Sat, 16 May 2009, Wu Fengguang wrote:
> vmscan: make mapped executable pages the first class citizen
Nice description! Can you also add the results of a test that shows the
benefit of this patch?
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-18 14:46 ` Christoph Lameter
@ 2009-05-19 3:27 ` Wu Fengguang
2009-05-19 4:41 ` KOSAKI Motohiro
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 3:27 UTC (permalink / raw)
To: Christoph Lameter
Cc: Andrew Morton, LKML, Elladan, Nick Piggin, Johannes Weiner,
KOSAKI Motohiro, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Mon, May 18, 2009 at 10:46:15PM +0800, Christoph Lameter wrote:
> On Sat, 16 May 2009, Wu Fengguang wrote:
>
> > vmscan: make mapped executable pages the first class citizen
>
> Nice description!
Thank you!
> Can you also add the results of a test that shows the benefit of
> this patch?
OK. Here it is
SUMMARY
=======
The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
SCENARIO
========
The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
where 10% of the pages will be activated:
for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
iotrace.rb --load pattern-hot-10 --play /b/sparse
and monitor /proc/vmstat during the time. The test box has 2G memory.
ANALYZES
========
I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
patch, and fetched the vmstat numbers on
(1) begin: shortly after the big read IO starts;
(2) end: just before the big read IO stops;
(3) restore: the big read IO stops and the zsh working set restored
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
begin: 2481 2237 8694 630 0 574299
end: 275 231976 233914 633 776271 20933042
restore: 370 232154 234524 691 777183 20958453
begin: 2434 2237 8493 629 0 574195
end: 284 231970 233536 632 771918 20896129
restore: 399 232218 234789 690 774526 20957909
and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
begin: 2479 2344 9659 210 0 579643
end: 284 232010 234142 260 772776 20917184
restore: 379 232159 234371 301 774888 20967849
The numbers show that
- The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
I'd attribute that improvement to the mmap readahead improvements :-)
- The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
That's a huge improvement - which means with the VM_EXEC protection logic,
active mmap pages is pretty safe even under partially cache hot streaming IO.
- when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
That roughly means the active mmap pages get 20.8 more chances to get
re-referenced to stay in memory.
- The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
dropped pages are mostly inactive ones. The patch has almost no impact in
this aspect, that means it won't unnecessarily increase memory pressure.
(In contrast, your 20% mmap protection ratio will keep them all, and
therefore eliminate the extra 41 major faults to restore working set
of zsh etc.)
RAW NUMBERS
===========
2.6.29 with VM_EXEC protection:
% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2291 2236 8256 618 0 573817
2415 2236 8473 629 0 574288
2481 2237 8694 630 0 574299
2481 2237 8784 630 0 574302
2484 5054 35432 630 0 603215
2484 8453 66861 630 0 640884
2484 12017 98113 630 0 678696
2484 15434 129512 630 0 715516
2484 18885 160628 630 0 754177
2484 22407 192170 630 0 790997
2484 25845 222804 630 0 829658
2484 29379 254830 630 0 866478
2484 32918 286107 630 0 905139
2484 36359 317482 630 0 943800
2484 39919 349761 630 0 980620
2484 43379 381024 630 0 1019281
2484 46889 412424 630 0 1056101
2484 51576 417827 630 4288 1112642
2484 54865 414277 630 5149 1179934
2484 58052 411414 630 5305 1247292
2484 61284 408370 630 5305 1314219
2484 64495 405096 630 5305 1381700
2484 67765 401637 630 5305 1449106
2484 70955 398920 630 5305 1516587
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2484 74225 395122 630 5305 1584926
2484 77495 391490 630 5305 1653110
2484 80744 388008 630 5305 1720128
2484 83983 385136 630 5305 1787562
2484 87244 382519 630 5305 1856522
2484 90505 379368 630 5305 1923957
2484 93797 375211 630 5305 1991843
2484 96965 372127 630 5305 2059025
2484 100154 369459 630 5305 2125794
2484 103405 365181 630 5305 2193589
2484 106575 361994 630 5305 2259542
2484 109806 358666 630 5305 2326361
2484 113034 355544 630 5305 2394012
2484 116318 352062 630 5305 2462832
2484 119516 349061 630 5305 2530325
2484 122755 346227 630 5305 2597400
2484 126028 342549 630 5305 2664795
2484 129247 339834 630 5305 2732030
2484 132416 336033 630 5305 2797594
2484 135648 332295 630 5305 2864787
2484 138878 329519 630 5305 2932054
2484 142098 326411 630 5305 2998663
2484 145289 323443 630 5305 3065131
2484 148460 319319 630 5305 3132863
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2484 151659 315919 630 5305 3200802
2484 154920 313764 630 5305 3267461
2484 158181 309460 630 5305 3335252
2484 161411 307124 630 5305 3402071
2484 164641 303445 630 5305 3469690
2484 167809 300304 630 5305 3536669
2484 171009 296526 630 5305 3602447
2484 174251 293013 630 5305 3669426
2484 177483 290077 630 5305 3736885
2484 180714 286435 630 5305 3804024
2484 183944 283499 630 5305 3871484
2484 187174 279857 630 5305 3938623
2484 190373 277112 630 5305 4005922
2484 193634 272672 630 5305 4074053
2484 196802 270632 630 5305 4140360
2484 199982 267629 630 5305 4206891
2484 203154 263384 630 5305 4272925
2484 206312 260751 630 5305 4339008
2484 209484 258033 630 5305 4405347
2484 212705 253705 630 5305 4473222
2484 215935 250463 630 5305 4539945
2484 219134 247148 630 5305 4605979
2484 222364 243916 630 5305 4672702
2484 225588 240250 630 5305 4739873
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2484 228685 237341 630 5305 4806404
2484 231886 234140 630 5305 4871543
2484 231986 234163 630 8418 4938905
2484 231957 234804 630 11610 5004860
2484 232177 234675 630 14570 5071647
2484 231905 234020 630 18050 5139298
2484 232092 233641 630 21074 5205498
2484 231868 234025 630 24506 5271959
2484 231873 233860 630 27674 5337830
2484 232004 233601 630 30682 5404659
2466 231782 233983 630 34122 5470432
2466 231815 233725 630 37314 5537383
2466 231832 233997 630 40522 5604845
2466 231904 233604 630 43706 5671893
2466 231882 233459 630 46922 5739066
2466 231909 234634 630 50058 5804997
2466 231988 234018 630 53173 5872013
2466 231834 234006 630 56500 5938229
2466 231986 233711 630 59604 6006458
2466 231905 234020 630 62900 6072048
2466 232012 233560 630 66028 6139127
2466 231926 233570 630 69308 6206367
2466 231961 234398 630 72436 6272228
2453 231964 233793 630 75596 6339340
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1098 231930 234024 630 78884 6404853
1105 231977 233574 630 82044 6471963
1105 231986 233566 630 85260 6539713
1105 231699 233234 630 88796 6607400
1105 232045 234211 630 91620 6673487
1105 232017 234473 630 94852 6739957
1105 231730 233854 630 98316 6807612
1105 232036 233649 630 101252 6874404
1105 231725 233955 630 104740 6940155
1105 231854 233665 630 107836 7007042
1105 231807 233969 630 111108 7074537
1105 231887 233600 630 114284 7141552
1105 231857 234015 630 117508 7208918
1105 231894 234285 630 120644 7274729
1105 231913 233606 630 123788 7341710
1105 231859 233981 630 127036 7407302
1105 231971 233580 630 130180 7474317
1105 231917 233470 630 133428 7541363
1105 231896 234036 630 136612 7607516
1105 231947 233604 630 139724 7672915
1105 231813 233779 630 143052 7740120
1105 231856 233980 630 146172 7805952
1105 231910 233641 630 149260 7872015
1105 231869 233756 630 152516 7938400
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1105 231834 234001 630 155724 8004328
1105 231854 233601 630 158836 8070234
1105 231823 233365 630 162092 8136804
1105 231748 233868 630 165268 8202733
1105 231854 233729 630 168356 8267651
1105 232129 233922 630 171292 8333847
1105 231811 233869 630 174756 8401010
1105 231885 233698 630 177876 8467832
1105 231799 233977 630 181156 8533550
1105 231866 234005 630 184324 8600150
1105 232071 234515 630 187268 8666173
1105 231793 233951 630 190692 8732773
1105 231810 233677 630 193900 8798908
1105 231875 233412 630 197060 8866115
1105 231862 234005 630 200236 8932138
1105 231850 233637 630 203380 8997961
1105 231811 233470 630 206644 9064677
1105 231791 233761 630 209796 9130637
1105 232011 233573 630 212756 9195680
1105 231779 233501 630 216196 9263060
1105 231760 234380 630 219388 9329018
1105 232026 233960 630 222292 9395714
1105 231781 233995 630 225724 9461401
1105 231862 234169 630 228868 9527840
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1105 232067 234518 630 231812 9594053
1105 231757 233955 630 235268 9659804
1105 231847 233704 630 238403 9726690
1105 231904 233457 630 241571 9793593
1105 231757 233827 630 244819 9860115
1105 232000 233552 630 247787 9926683
1105 231810 233966 630 251195 9992560
1105 231891 234140 630 254339 10059027
1105 232062 234513 630 257307 10125213
668 231778 233966 630 260747 10190928
275 231819 234404 630 263931 10257141
275 232088 234487 630 266811 10323547
275 231746 233902 630 270299 10389361
275 231851 233636 630 273419 10456248
275 231740 233661 630 276755 10523806
275 231817 233735 630 279851 10589636
275 231988 233596 630 282819 10655304
275 231788 233373 630 286237 10721856
275 231784 233864 630 289373 10787879
275 232020 233511 630 292317 10854701
275 231748 233996 630 295797 10920417
275 231853 233954 630 298917 10987061
275 232112 234175 630 301869 11053294
275 231748 233932 630 305317 11120629
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231853 233698 630 308437 11185673
275 231790 233583 630 311725 11253211
275 231811 234582 630 314877 11319007
275 232012 234499 630 317877 11385924
275 231768 234008 630 321277 11453178
275 231841 233646 630 324429 11518558
275 231810 233442 630 327685 11585924
275 231856 234331 630 330813 11651807
275 231858 233829 630 334005 11718629
275 231789 233966 630 337237 11784378
275 231869 233693 630 340413 11851297
275 231862 233989 630 343645 11918760
275 231943 234067 630 346789 11985307
275 231863 234566 630 349949 12051506
275 231857 233962 630 353149 12117126
275 231921 233929 630 356341 12183815
275 231862 234755 630 359501 12249776
275 231777 233978 630 362749 12315523
275 231905 233561 630 365877 12382537
275 231795 233776 630 369181 12449934
275 231894 234325 630 372245 12515731
275 231873 233593 630 375429 12582712
275 231866 234049 630 378661 12648171
275 231965 233949 630 381797 12714879
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231999 234457 630 384957 12781077
275 231828 233959 630 388229 12848475
275 231933 233629 630 391349 12914212
275 231799 233834 630 394677 12981076
275 231898 233920 630 397741 13046811
275 231856 233693 630 400933 13111921
275 231831 233679 630 404165 13179383
275 231898 234644 633 407261 13245225
284 231911 234497 633 410421 13312238
284 231854 233944 633 413693 13377856
284 231953 233556 633 416829 13444869
284 231835 233655 633 420141 13512266
284 231926 234710 633 423213 13577998
284 231937 234377 633 426365 13645076
284 231850 233988 633 429685 13710623
284 231988 233594 633 432773 13777603
284 231974 233546 633 435981 13844360
284 231611 234132 633 439445 13909053
284 231893 234329 633 442357 13975267
284 231899 234674 633 445493 14041674
284 231806 233937 633 448749 14107390
284 231974 233576 633 451837 14174306
284 231994 233984 633 455021 14240572
284 231822 233921 633 458253 14306495
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231918 233632 633 461413 14372641
284 231993 234580 633 464501 14438342
284 231790 233953 633 467805 14504906
284 231879 233703 633 470972 14570942
284 232025 233623 633 474020 14637540
284 231868 233779 633 477340 14704331
284 231857 233661 633 480524 14771185
284 231843 233996 633 483732 14836777
284 231886 234725 633 486852 14902574
284 231897 233682 633 490004 14969555
284 231827 233980 633 493268 15035147
284 231806 234337 633 496452 15101008
284 231888 233818 633 499564 15167796
284 231779 233964 633 502836 15233555
284 231931 233587 633 505940 15300503
284 231805 233418 633 509260 15367801
284 231834 233813 633 512404 15433825
284 231864 233718 633 515506 15498907
284 231821 233832 633 518774 15566267
284 231840 234645 633 521918 15632127
284 231922 234156 633 525030 15698946
284 231829 233946 633 528286 15764663
284 231901 233585 633 531470 15831676
284 231895 233464 633 534670 15898530
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231914 233893 633 537814 15964807
284 231896 233622 633 540974 16031418
284 231902 233969 633 544214 16097373
284 231977 233573 633 547374 16164418
284 231955 233530 633 550590 16231285
284 231854 234478 633 553854 16297675
284 231929 233960 633 556942 16364657
284 231866 234005 633 560230 16430181
284 231917 234561 633 563342 16496266
284 231968 234264 633 566454 16562926
284 231890 234013 633 569726 16628483
284 231971 233579 633 572870 16695561
284 231855 233781 633 576190 16762892
284 231930 234530 633 579278 16828690
284 231933 234268 633 582438 16895736
284 231881 233553 633 585726 16961760
284 231978 233551 633 588854 17028389
284 232092 234143 633 591934 17094373
284 231865 234017 633 595262 17159833
284 231970 233527 633 598382 17226765
284 231868 233458 633 601678 17294047
284 231880 233970 633 604798 17359860
284 231914 233615 633 607958 17425267
284 231886 233947 633 611190 17492365
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231953 234546 633 614286 17558257
284 231916 233861 633 617486 17625238
284 231877 234005 633 620750 17690792
284 231943 234386 633 623878 17757053
284 231899 234125 633 627054 17823605
284 231830 233678 633 630286 17889193
284 231850 233904 633 633398 17954958
284 231940 233621 633 636502 18020034
284 231846 233693 633 639790 18087528
284 231843 234189 633 642966 18153324
284 231902 233563 633 646070 18220307
284 231784 234034 633 649382 18285863
284 231835 234782 633 652494 18351788
284 231934 233789 633 655582 18418610
284 231800 233922 633 658886 18484293
284 231866 234265 633 661990 18550092
284 231862 233701 633 665134 18615041
284 231952 233547 633 668254 18681807
284 231712 233947 633 671574 18746554
284 232104 233907 633 674414 18812895
284 232009 234173 633 677598 18879108
284 231696 233802 633 681110 18945047
284 232094 233746 633 683934 19011389
275 232063 234491 633 687126 19077443
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231632 233810 633 690694 19143446
275 231971 233527 633 693566 19210118
275 231746 233478 633 697030 19277707
275 231777 233972 633 700178 19343505
275 231980 233550 633 703077 19410105
275 231733 233398 633 706573 19476043
275 232054 233743 633 709405 19541713
275 232003 233544 633 712621 19608567
275 231717 233879 633 716109 19674380
275 232039 233581 633 718957 19740306
275 231917 233556 633 722197 19805161
275 232015 233598 633 725317 19871706
275 232033 234459 633 728389 19937490
275 231920 233668 633 731701 20003365
275 232015 233610 633 734837 20070039
275 232017 233571 633 738029 20137007
275 231951 233502 633 741245 20203667
275 231975 233558 633 744397 20268952
275 231936 234053 633 747640 20335755
275 231941 234723 633 750807 20401648
275 232003 234363 633 753919 20468693
275 231936 233562 633 757191 20534601
275 231703 233244 633 760663 20602093
275 231904 233507 633 763631 20668531
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231952 233924 633 766751 20734392
275 232002 233576 633 769887 20799595
275 231960 234066 633 773119 20866798
275 231976 233914 633 776271 20933042
380 232138 234504 691 777183 20958440
370 232154 234513 691 777183 20958440
370 232154 234513 691 777183 20958440
370 232154 234513 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958452
370 232154 234524 691 777183 20958453
370 232154 234524 691 777183 20958453
% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2434 2237 8493 629 0 574195
2438 2238 8683 629 0 574215
2438 2331 11501 629 0 574303
2441 5675 41599 629 0 610507
2441 9137 72271 629 0 647327
2441 12638 103601 629 0 686002
2442 16118 134919 629 0 722822
2442 19507 166348 629 0 760491
2442 23040 197624 629 0 798303
2442 26489 229010 629 0 835123
2442 30063 260270 629 0 873784
2442 33511 291592 629 0 912445
2442 37033 323924 629 0 949265
2442 40512 355053 629 0 987926
2442 44003 386586 629 0 1024746
2442 47544 417862 629 0 1063407
2442 52116 416531 629 2752 1124077
2442 55340 413069 629 2752 1191875
2442 58611 410119 629 2752 1258804
2442 61800 406875 629 2752 1326345
2442 65030 404213 629 2752 1392938
2442 68229 400524 629 2752 1460840
2442 71521 397357 629 2752 1528052
2442 74751 394412 629 2752 1595612
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2442 77981 391130 629 2752 1663527
2442 81211 387648 629 2752 1730514
2442 84441 384680 629 2752 1798045
2442 87711 381843 629 2752 1867078
2442 90963 378694 629 2752 1934451
2442 94253 375455 629 2752 2001637
2442 97422 371732 629 2752 2069433
2442 100652 369063 629 2752 2136205
2442 103883 364909 629 2752 2203998
2442 107061 361629 629 2752 2269904
2442 110281 358301 629 2752 2336891
2442 113511 354923 629 2752 2404642
2442 116793 351821 629 2752 2473206
2442 120002 348602 629 2752 2540793
2442 123232 346050 629 2752 2607772
2442 126524 341930 629 2752 2675423
2442 129723 339492 629 2752 2742402
2442 132881 335542 629 2752 2808052
2442 136113 331954 629 2752 2875127
2442 139355 329146 629 2752 2942454
2442 142535 326367 629 2752 3008747
2442 145703 323107 629 2752 3075584
2442 148944 318828 629 2752 3143363
2442 152124 316560 629 2752 3210182
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2442 155375 312250 629 2752 3277961
2442 158574 309031 629 2752 3343899
2442 161837 305734 629 2752 3412559
2442 165024 302613 629 2752 3478337
2442 168256 299131 629 2752 3545316
2442 171466 295570 629 2752 3612935
2442 174645 293642 629 2752 3678794
2442 177805 289974 629 2752 3745774
2442 181017 286387 629 2752 3813090
2442 184257 282869 629 2752 3880372
2442 187477 279778 629 2752 3945990
2442 190707 276126 629 2752 4014540
2442 193938 273350 629 2752 4080428
2442 197167 269547 629 2752 4147728
2442 200337 266386 629 2752 4214419
2442 203457 263605 629 2752 4278981
2442 206687 259867 629 2752 4346216
2442 209860 257663 629 2752 4411973
2442 213039 253767 629 2752 4479418
2442 216207 250219 629 2752 4546525
2442 219418 246867 629 2752 4612559
2442 222650 243897 629 2752 4679008
2442 225727 241363 629 2752 4745109
2442 228938 237593 629 2752 4810631
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2442 232182 233855 629 2752 4877866
2442 232295 234248 629 5825 4944027
2442 232130 234310 629 9153 5011088
2442 232124 234428 629 12353 5078163
2442 232070 234152 629 15601 5143749
2442 232117 233658 629 18793 5210920
2442 231993 233951 629 22097 5278283
2442 231989 234468 629 25281 5344174
2424 232031 234614 629 28409 5411249
2424 232010 233541 629 31681 5479064
2424 231713 233902 629 35177 5544910
2424 232046 233537 629 38105 5613511
2424 231779 233965 629 41561 5679262
2424 231909 233740 629 44673 5746085
2424 231781 233681 629 48009 5813772
2424 231827 234807 629 51132 5879571
2424 231903 233480 629 54347 5947799
2424 231922 234300 629 57563 6014448
2424 231912 233475 629 60795 6082347
2424 232022 233912 629 63923 6149216
2424 232045 234012 629 67099 6215770
2424 231984 234417 629 70339 6282656
2246 231994 234343 629 73499 6349801
1105 231933 234044 629 76779 6416563
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1105 231991 234377 629 79963 6484276
1105 231979 233554 629 83187 6551674
1105 231736 233889 629 86675 6617873
1105 232001 233617 629 89635 6684600
1105 231770 233735 629 93091 6752224
1105 231828 234766 629 96227 6818101
1105 231924 233443 629 99387 6886127
1105 231846 234802 629 102659 6952516
1105 231966 233560 629 105795 7020489
1105 231991 234433 629 108995 7087217
1105 231954 234566 629 112203 7153863
1105 231848 234033 629 115443 7219389
1105 231960 233576 629 118587 7286470
1105 231850 233475 629 121891 7353774
1105 231932 234812 629 125003 7419731
1105 232071 234512 629 128099 7486655
1105 231880 233696 629 131427 7554373
1105 232025 233635 629 134523 7621100
1105 231917 234006 629 137835 7686657
1105 232037 234547 629 140899 7752709
1105 232012 234604 629 144107 7819409
1105 231972 233992 629 147339 7886775
1105 231990 234136 629 150507 7953885
1105 231966 233602 629 153763 8019826
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1105 231726 233775 629 157235 8087512
1105 231994 233711 629 160147 8153664
1105 231997 233719 629 163307 8220007
1105 231998 233569 629 166475 8286702
1105 231998 233576 629 169707 8352656
1105 232092 233848 629 172843 8418963
1105 232140 233803 629 175971 8485804
1105 232049 233988 629 179235 8552806
1105 231738 233919 629 182723 8618652
1105 231936 233562 629 185755 8685539
1105 231947 234030 629 188795 8748923
1105 231762 233314 629 192219 8816704
1105 231966 233985 629 195195 8883240
1105 231993 234759 629 198331 8949103
1105 232035 234145 629 201483 9016247
1105 231997 233628 629 204715 9082092
1105 231726 233344 629 208235 9149743
1105 232056 233963 629 211075 9215866
1105 232043 234138 629 214251 9282339
1105 231726 233899 629 217755 9348186
1105 231993 233632 629 220699 9414913
1105 231736 233302 629 224195 9482582
1105 231755 234394 629 227339 9548461
1105 232055 234033 629 230219 9615155
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1105 231754 233999 629 233707 9680872
1105 232027 233598 629 236666 9747726
1105 232101 234131 629 239786 9813826
1105 231739 233918 629 243242 9881148
1105 231987 233606 629 246226 9946097
1105 231773 233948 629 249658 10013720
1105 231816 234461 629 252778 10079485
1105 232076 234014 629 255698 10146245
286 231717 233844 629 259234 10212217
275 231846 234066 629 262330 10278591
275 232138 234510 629 265218 10344593
275 231710 233851 629 268802 10412407
275 232038 233586 629 271706 10479100
275 231801 233984 629 275130 10544817
275 231874 234006 629 278282 10611414
275 232045 233581 629 281336 10678372
275 231884 234117 629 284660 10745028
275 231918 234697 629 287820 10811915
275 231769 233984 629 291132 10878734
275 231937 233655 629 294220 10945400
275 231890 234023 629 297492 11011980
275 231924 234244 629 300652 11078430
275 231999 234423 629 303812 11144947
275 231938 234191 629 307036 11212188
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231893 234440 629 310244 11279298
275 231902 234043 629 313460 11345607
275 231991 233662 629 316596 11413708
275 231912 234065 629 319900 11479201
275 232001 233623 629 323036 11546279
275 231931 234081 629 326300 11613550
275 232032 234531 629 329404 11679815
275 232128 234149 629 332564 11746811
275 232027 233977 629 335828 11814323
275 231662 233782 629 339380 11880296
275 232001 233582 629 342252 11946861
275 231776 233369 629 345716 12014400
275 231741 233927 629 348852 12080247
275 232001 233603 629 351772 12145196
275 231896 233493 629 355092 12212095
275 232101 234493 629 358060 12277655
275 231937 233603 629 361356 12343609
275 231786 233363 629 364756 12410972
275 232100 234398 629 367612 12476066
275 231955 233563 629 370868 12541974
275 231802 233379 629 374260 12609257
275 232094 233969 629 377148 12674830
275 231955 233617 629 380388 12740432
275 231690 233541 629 383892 12807993
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231966 233777 629 386796 12874208
275 231993 234139 629 389932 12940356
275 232019 233584 629 393100 13007113
275 231981 234039 629 396332 13072574
275 231977 234619 629 399468 13138724
275 232006 234371 629 402612 13205483
275 231965 233543 629 405868 13271456
275 231870 233415 629 409212 13338340
275 232042 233621 629 412220 13404934
275 231968 233559 629 415444 13471601
275 231662 233782 629 418940 13537606
275 232017 233587 629 421796 13604172
275 232035 234592 629 424972 13669873
275 232031 234563 629 428108 13736630
275 231977 233563 629 431356 13802572
275 232043 234424 629 434484 13868351
275 231978 234368 629 437660 13934966
275 231939 234081 629 440924 14000427
275 231943 233784 629 444052 14066575
275 231954 233585 629 447204 14131492
275 231892 233757 629 450460 14198730
275 231951 234345 629 453564 14264559
275 232017 234174 629 456692 14331647
275 231923 233617 629 459980 14397586
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 232015 234151 629 463100 14463665
275 231998 234627 629 466272 14529979
275 231902 233744 629 469531 14595825
275 231991 233612 629 472667 14662582
275 232057 234284 629 475795 14728508
275 231862 234030 629 479091 14793906
275 231967 233636 629 482211 14860920
275 232073 234076 629 485299 14927070
275 231869 234023 629 488635 14994082
275 231954 233636 629 491731 15061098
275 231867 234131 629 495035 15126622
275 231995 234664 629 498091 15192642
275 232039 234522 629 501251 15259527
275 231882 234042 629 504571 15325020
275 232019 233584 629 507659 15392064
275 231909 233863 629 510963 15459397
275 231973 234418 629 514062 15525131
275 232048 233928 629 517181 15592209
275 231898 234090 629 520525 15657766
275 231980 234487 629 523637 15723978
275 232039 234523 629 526741 15790640
275 231906 234018 629 530037 15856163
275 231997 233574 629 533181 15923239
275 232040 234554 629 536301 15988940
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231932 234024 629 539541 16055975
275 231989 233614 629 542709 16123384
275 231902 234054 629 546021 16188941
275 231861 233424 629 549301 16256287
275 231969 233714 629 552373 16323236
275 231956 234714 629 555549 16389096
275 232046 234580 629 558653 16456206
275 231984 233556 629 561909 16523690
275 231713 233859 629 565429 16589897
275 231980 233603 629 568373 16656593
275 231731 233905 629 571861 16724310
275 231804 234151 629 575013 16790703
275 232159 234244 629 577869 16856974
275 231747 233921 629 581365 16922612
275 232008 233575 629 584357 16989421
275 231936 233488 629 587637 17056270
275 231736 233879 629 590917 17122840
275 232032 233583 629 593853 17187724
275 231754 233343 629 597349 17255155
275 231688 233863 629 600485 17319397
275 231987 233607 629 603397 17386058
275 232038 234536 629 606509 17451824
275 231720 233895 629 609973 17517668
275 231987 233628 629 612917 17584392
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 232084 234298 629 616045 17650348
275 232056 234548 629 619205 17716880
275 231939 233644 629 622485 17782755
275 231993 234593 629 625573 17848423
275 232033 234015 629 628717 17915148
275 231955 233660 629 631989 17981056
275 231945 234859 629 635141 18046406
275 231976 233544 629 638277 18113579
275 231941 234049 629 641533 18179009
275 231956 235004 629 644637 18244741
275 231976 234148 632 647797 18311864
284 231902 234076 632 651061 18377453
284 231944 233939 632 654181 18443251
284 231974 233581 632 657301 18508455
284 232048 233957 632 660429 18574682
284 231838 234012 632 663725 18639776
284 231905 234361 632 666893 18706067
284 231931 234327 632 669965 18772385
284 231807 234020 632 673285 18838133
284 231866 234331 632 676389 18903897
284 231924 233741 632 679525 18970781
284 231791 233940 632 682821 19036562
284 231865 234537 632 685941 19102584
284 232030 234588 632 688949 19169148
+72904 +1518800
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231807 233988 632 692325 19235242
284 231898 233736 632 695469 19301718
284 231948 233554 632 698644 19368757
284 231832 233931 632 701892 19435041
284 231883 233751 632 705004 19500240
284 231812 233922 632 708300 19567609
284 231871 234201 632 711404 19633405
284 231929 233704 632 714540 19700258
284 231780 233983 632 717852 19766007
284 231871 234852 632 720924 19831742
284 232042 234057 632 723932 19898564
284 231798 233997 632 727364 19964311
284 231871 233635 632 730516 20031323
284 231896 233509 632 733716 20098334
284 231835 233895 632 736940 20164578
284 231933 233886 632 740036 20231399
284 231792 233971 632 743340 20297158
284 231934 233604 632 746454 20364106
284 231952 233524 632 749630 20430863
284 231899 233988 632 752846 20497333
284 231888 234055 632 756030 20564219
284 231863 233996 632 759270 20629871
284 231962 233608 632 762406 20696883
284 231956 233552 632 765606 20763640
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231935 233924 632 768790 20830044
284 231970 233536 632 771918 20896129
346 232160 234770 686 774526 20957437
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957892
399 232218 234778 690 774526 20957893
399 232218 234778 690 774526 20957893
399 232218 234778 690 774526 20957893
399 232218 234789 690 774526 20957909
399 232218 234789 690 774526 20957909
2.6.30-rc4-mm1 without VM_EXEC protection:
% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2289 2343 9104 203 0 579085
2289 2343 9104 203 0 579539
2471 2344 9572 210 0 579641
2479 2344 9659 210 0 579643
2479 5289 38207 210 0 610397
2482 9074 72302 210 0 650979
2482 12824 105416 210 0 691481
2482 16592 139536 210 0 733825
2482 20355 173670 210 0 774337
2482 24197 207706 210 0 814840
2482 27937 241854 210 0 855342
2482 31808 276489 210 0 897687
2482 35579 310980 210 0 938189
2482 39431 345047 210 0 980534
2482 43240 379138 210 0 1021036
2482 47019 413241 210 0 1063380
2482 52260 416287 210 2976 1130630
2482 55842 412718 210 2976 1205132
2482 59372 409640 210 2976 1279194
2482 62942 406386 210 2976 1352429
2482 66452 402808 210 2976 1426994
2482 69994 398164 210 2976 1501599
2482 73595 394937 210 2976 1575747
2482 77145 391132 210 2976 1650510
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2482 80492 388103 210 2976 1725204
2482 84062 384532 210 2976 1800337
2482 87445 380942 210 2976 1875056
2482 91015 377106 210 2976 1949815
2482 94564 373549 210 2976 2023356
2482 98059 370849 210 2976 2096912
2482 101620 366238 210 2976 2171674
2482 104995 362720 210 2976 2244601
2482 108567 359153 210 2976 2318078
2482 111901 355563 210 2976 2392819
2482 115451 352494 210 2976 2466905
2482 118980 349152 210 2976 2541233
2482 122551 345285 210 2976 2614962
2482 126113 342388 210 2976 2688972
2482 129621 338839 210 2976 2763473
2482 133131 334191 210 2976 2836262
2482 136723 330930 210 2976 2910611
2482 140287 326605 210 2976 2984775
2482 143764 324762 210 2976 3057694
2482 147243 320252 210 2976 3131963
2482 150827 316352 210 2976 3205274
2482 154397 312721 210 2976 3278816
2482 157967 309162 210 2976 3353380
2482 161528 305576 210 2976 3427882
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2482 165061 302027 210 2976 3502063
2482 168538 298928 210 2976 3575091
2482 172081 294769 210 2976 3647911
2482 175601 292199 210 2976 3720397
2482 179081 288771 210 2976 3794930
2482 182633 284220 210 2976 3869432
2482 186172 280831 210 2976 3942341
2482 189742 277112 210 2976 4016673
2482 193315 273093 210 2976 4091334
2482 196774 270122 210 2976 4163596
2482 200287 266444 210 2976 4236532
2482 203703 263161 210 2976 4308858
2482 207268 259474 210 2976 4381646
2482 210838 255351 210 2976 4455666
2482 214349 252997 210 2976 4529047
2482 217901 248585 210 2976 4603393
2482 221440 245816 210 2976 4677127
2482 224939 241265 210 2976 4749788
2482 228503 237940 210 2976 4824047
2482 231949 235169 210 2976 4896872
2482 232107 233917 210 6360 4971106
2482 232169 233760 210 9864 5044194
2482 232137 234282 210 13424 5118215
2482 232038 234689 210 17072 5191373
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2482 232024 233617 210 20528 5265387
2482 231989 234068 210 24112 5338184
1633 232017 234121 210 27656 5411131
1587 231949 233573 210 31248 5483873
1587 231850 233982 210 34896 5558055
1587 232088 234191 210 38224 5631094
1587 231967 233481 210 41832 5705470
1587 231768 233872 210 45528 5777946
1587 232038 233825 210 48824 5851185
1587 231869 234363 210 52480 5924857
1587 231668 233908 210 56168 5997712
1587 231570 233846 210 59856 6072410
1587 231904 233479 210 63088 6145967
1612 231594 233792 219 66792 6218018
1615 231566 233568 219 70400 6292701
1615 231793 234747 219 73648 6364918
275 231637 233748 219 77520 6439606
275 231845 234435 219 80816 6513184
275 231801 233455 219 84440 6585880
275 231727 233586 219 88088 6660339
275 231793 233940 219 91560 6734426
275 231826 234481 219 95024 6807336
275 231855 233430 219 98520 6880864
275 231864 233495 219 102080 6954454
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231957 234159 219 105512 7027167
275 231924 233393 219 109032 7101461
275 231828 233841 219 112656 7173782
275 231673 233836 219 116360 7248452
275 231930 234442 219 119576 7321068
275 231720 233885 219 123304 7395314
275 231615 233766 219 126968 7468198
275 231603 233714 219 130560 7542765
275 231857 233427 219 133872 7616274
275 231785 234150 219 137472 7690087
275 231917 234104 219 140896 7764542
275 231869 234438 219 144472 7837732
275 231778 234561 219 148112 7912201
275 231850 233467 219 151544 7986152
275 231838 233447 219 155136 8059397
275 231677 233832 219 158856 8133675
275 231641 233836 219 162472 8208212
275 231905 234435 219 165712 8280826
275 231758 234711 219 169408 8355167
275 231700 233713 219 173056 8429750
275 231884 234487 219 176376 8503291
275 231841 233475 219 179968 8577274
275 231670 233678 219 183688 8650455
275 231877 234016 219 187016 8724413
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231868 234438 219 190584 8797506
275 231877 233482 219 194048 8871912
275 231850 233467 219 197624 8944604
275 231751 233886 219 201272 9018786
275 231904 234436 219 204592 9091561
275 231832 233431 219 208192 9164286
275 231677 233832 219 211896 9238531
275 231609 233804 219 215544 9313130
275 231959 233709 219 218760 9386349
275 231712 234756 219 222504 9460053
275 231543 233678 219 226160 9534447
275 231848 233423 219 229408 9606351
275 231753 233659 219 233096 9680706
275 231955 234149 219 236384 9753491
275 231859 233425 219 239960 9827808
275 231712 233636 219 243656 9900405
275 231918 233975 219 247016 9974344
275 231940 234399 219 250512 10047393
275 231876 233409 219 254080 10121926
275 231844 233483 219 257640 10194556
275 231921 233653 219 261112 10267755
275 231954 233395 219 264552 10341479
275 231840 233477 219 268184 10414172
275 231671 233806 219 271912 10488514
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 232021 233913 219 275128 10561524
275 231806 233543 219 278768 10635614
275 231662 233858 219 282536 10708103
275 231872 233445 219 285936 10781785
275 231817 234810 219 289464 10854982
275 231640 233772 219 293128 10929687
275 231630 233760 219 296728 11002396
275 231898 233481 219 300016 11075882
275 231707 234632 219 303704 11149428
275 231898 234440 219 307048 11222912
275 231888 234483 219 310576 11297363
275 231835 233512 219 314240 11371912
275 231891 233457 219 317688 11444589
275 231865 233877 219 321304 11518711
275 232024 233663 219 324680 11592202
275 231938 233476 219 328224 11666015
229 231848 233879 219 331952 11738375
207 231695 233904 219 335664 11813007
207 231667 233772 219 339272 11887671
207 231874 234140 219 342600 11960561
182 231761 233742 219 346200 12034573
179 231889 233517 219 349576 12106308
179 231911 233495 219 353144 12180810
179 231702 233673 219 356840 12254322
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
179 231942 234519 219 360104 12327738
179 231851 233523 219 363744 12400468
179 231929 233510 219 367232 12474907
179 232026 234466 219 370632 12547363
179 231793 233647 219 374336 12620657
179 231939 233725 219 377760 12694274
240 231864 234467 230 381296 12767642
275 231885 233512 237 384784 12842367
275 231860 233472 237 388360 12915091
275 231858 233937 237 391936 12989196
275 231974 234478 237 395288 13062001
275 231891 233530 237 398872 13136503
275 231793 233955 237 402536 13208844
275 231685 233839 237 406320 13283570
275 231889 233444 237 409696 13357203
275 231889 234754 237 413200 13430403
275 231683 233745 237 416872 13503690
275 231937 233522 237 420184 13578238
275 231821 233542 237 423880 13651326
275 231700 234688 237 427488 13724772
275 231916 234470 237 430776 13798281
275 231852 233543 237 434368 13870910
275 231979 234067 237 437776 13944771
275 231851 234504 237 441360 14017897
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231736 233691 237 445024 14090495
275 231974 233678 237 448352 14164759
275 231989 233898 237 451896 14238022
275 231958 234440 237 455400 14311984
275 231916 233512 237 458960 14384612
275 231848 233932 237 462608 14458762
275 232016 234403 237 465944 14531600
275 231874 233564 237 469552 14604637
275 231743 233973 237 473232 14678442
275 231803 233370 237 476752 14752415
275 231908 234895 237 480120 14825334
275 231717 233839 237 483808 14898219
275 231665 233795 237 487440 14972833
275 231897 234618 237 490712 15045223
275 231697 233891 237 494368 15119329
275 231879 233516 237 497752 15193331
275 231845 233614 237 501376 15265927
275 231692 234695 237 505016 15339501
275 231974 234494 237 508256 15412914
275 231873 233490 237 511888 15486268
275 231911 233549 237 515416 15560044
275 231823 234063 237 519032 15634131
275 231963 233786 237 522472 15707700
275 231979 234408 237 525960 15781598
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231906 233554 237 529520 15855678
275 231785 233931 237 533200 15928414
275 232060 233648 237 536560 16001878
275 231933 234549 237 540200 16075626
275 231772 233847 237 543848 16149417
275 231658 233897 237 547552 16222693
275 231920 233506 237 550856 16296304
275 231790 234532 237 554504 16369894
275 231630 233733 237 558120 16444349
275 231908 233486 237 561408 16515960
275 231755 234247 237 565120 16589824
275 231962 234147 237 568448 16664263
275 231960 234521 237 571968 16737370
275 231815 233579 237 575600 16811944
275 231973 233902 237 579008 16884115
275 231957 234524 237 582552 16957007
275 231898 233535 237 586144 17031515
275 231934 233520 237 589688 17104175
275 231819 234019 237 593352 17178310
275 231995 234482 237 596680 17251147
275 231908 233556 237 600264 17325650
275 231721 233893 237 604000 17398153
275 231925 233530 237 607376 17471741
275 231910 234919 237 610864 17544916
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231759 233823 237 614512 17619311
275 231669 233835 237 618200 17692398
275 231905 233548 237 621512 17765908
275 231720 234758 237 625184 17839356
275 231983 234461 237 628456 17912898
275 231895 233462 237 632072 17986912
275 231828 233625 237 635688 18060029
275 231899 234131 237 639152 18133955
275 231914 234530 237 642624 18207017
275 231921 233501 237 646152 18279677
275 231855 234079 237 649736 18353667
275 231896 234484 237 653192 18426696
275 231936 233518 237 656656 18499262
213 231893 234041 237 660248 18573283
179 231942 234535 237 663672 18646217
179 231918 233546 237 667224 18718877
179 231835 234035 237 670856 18792963
179 231980 234465 237 674184 18865864
179 231890 233532 237 677792 18938526
179 231793 233949 237 681448 19012707
179 232072 234415 237 684704 19085449
179 231911 233927 237 688352 19159567
179 231725 233921 237 692056 19232420
179 231883 233444 237 695488 19306167
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
279 231711 233823 260 699040 19378595
284 231912 234421 260 702312 19451272
284 231822 233552 260 705920 19523869
284 231723 233907 260 709568 19598188
284 231958 234513 260 712816 19670834
284 231725 233937 260 716536 19743899
284 231733 233909 260 720184 19817821
284 231947 234875 260 723472 19890117
284 231754 233917 260 727152 19962906
284 231704 233807 260 730792 20037568
284 231849 234813 260 734120 20109894
284 231720 233855 260 737736 20182619
284 231620 233827 260 741416 20257250
284 231859 234387 260 744712 20329909
284 231654 233857 260 748352 20402300
284 231911 233554 260 751648 20475809
284 231826 234420 260 755264 20549535
284 232000 234151 260 758656 20624140
284 232013 234487 260 762192 20697299
284 231814 233632 260 765888 20771800
284 231927 233517 260 769328 20844461
284 232010 234142 260 772776 20917184
346 232134 234358 301 774888 20967746
379 232159 234371 301 774888 20967746
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
379 232159 234371 301 774888 20967848
379 232159 234371 301 774888 20967848
379 232159 234371 301 774888 20967849
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 3:27 ` Wu Fengguang
@ 2009-05-19 4:41 ` KOSAKI Motohiro
2009-05-19 4:44 ` KOSAKI Motohiro
` (3 more replies)
0 siblings, 4 replies; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 4:41 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
Hi
Thanks for great works.
> SUMMARY
> =======
> The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
>
>
> SCENARIO
> ========
> The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> where 10% of the pages will be activated:
>
> for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> iotrace.rb --load pattern-hot-10 --play /b/sparse
Which can I download iotrace.rb?
> and monitor /proc/vmstat during the time. The test box has 2G memory.
>
>
> ANALYZES
> ========
>
> I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> patch, and fetched the vmstat numbers on
>
> (1) begin: shortly after the big read IO starts;
> (2) end: just before the big read IO stops;
> (3) restore: the big read IO stops and the zsh working set restored
>
> nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> begin: 2481 2237 8694 630 0 574299
> end: 275 231976 233914 633 776271 20933042
> restore: 370 232154 234524 691 777183 20958453
>
> begin: 2434 2237 8493 629 0 574195
> end: 284 231970 233536 632 771918 20896129
> restore: 399 232218 234789 690 774526 20957909
>
> and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
I don't think it is proper comparision.
you need either following comparision. otherwise we insert many guess into the analysis.
- 2.6.29 with and without VM_EXEC patch
- 2.6.30-rc4-mm with and without VM_EXEC patch
>
> begin: 2479 2344 9659 210 0 579643
> end: 284 232010 234142 260 772776 20917184
> restore: 379 232159 234371 301 774888 20967849
>
> The numbers show that
>
> - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> I'd attribute that improvement to the mmap readahead improvements :-)
>
> - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> That's a huge improvement - which means with the VM_EXEC protection logic,
> active mmap pages is pretty safe even under partially cache hot streaming IO.
>
> - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> That roughly means the active mmap pages get 20.8 more chances to get
> re-referenced to stay in memory.
>
> - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> dropped pages are mostly inactive ones. The patch has almost no impact in
> this aspect, that means it won't unnecessarily increase memory pressure.
> (In contrast, your 20% mmap protection ratio will keep them all, and
> therefore eliminate the extra 41 major faults to restore working set
> of zsh etc.)
I'm surprised this.
Why your patch don't protect mapped page from streaming io?
I strongly hope reproduce myself, please teach me reproduce way.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 4:41 ` KOSAKI Motohiro
@ 2009-05-19 4:44 ` KOSAKI Motohiro
2009-05-19 4:48 ` Wu Fengguang
2009-05-19 5:09 ` Wu Fengguang
` (2 subsequent siblings)
3 siblings, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 4:44 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: kosaki.motohiro, Wu Fengguang, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
> > begin: 2479 2344 9659 210 0 579643
> > end: 284 232010 234142 260 772776 20917184
> > restore: 379 232159 234371 301 774888 20967849
> >
> > The numbers show that
> >
> > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > I'd attribute that improvement to the mmap readahead improvements :-)
> >
> > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > That's a huge improvement - which means with the VM_EXEC protection logic,
> > active mmap pages is pretty safe even under partially cache hot streaming IO.
> >
> > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > That roughly means the active mmap pages get 20.8 more chances to get
> > re-referenced to stay in memory.
> >
> > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > dropped pages are mostly inactive ones. The patch has almost no impact in
> > this aspect, that means it won't unnecessarily increase memory pressure.
> > (In contrast, your 20% mmap protection ratio will keep them all, and
> > therefore eliminate the extra 41 major faults to restore working set
> > of zsh etc.)
>
> I'm surprised this.
> Why your patch don't protect mapped page from streaming io?
I guess you use initlevel=5 and use only terminal, right?
if so, dropping some graphics component makes sense.
>
> I strongly hope reproduce myself, please teach me reproduce way.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 4:44 ` KOSAKI Motohiro
@ 2009-05-19 4:48 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 4:48 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 12:44:19PM +0800, KOSAKI Motohiro wrote:
> > > begin: 2479 2344 9659 210 0 579643
> > > end: 284 232010 234142 260 772776 20917184
> > > restore: 379 232159 234371 301 774888 20967849
> > >
> > > The numbers show that
> > >
> > > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > > I'd attribute that improvement to the mmap readahead improvements :-)
> > >
> > > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > > That's a huge improvement - which means with the VM_EXEC protection logic,
> > > active mmap pages is pretty safe even under partially cache hot streaming IO.
> > >
> > > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > > That roughly means the active mmap pages get 20.8 more chances to get
> > > re-referenced to stay in memory.
> > >
> > > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > > dropped pages are mostly inactive ones. The patch has almost no impact in
> > > this aspect, that means it won't unnecessarily increase memory pressure.
> > > (In contrast, your 20% mmap protection ratio will keep them all, and
> > > therefore eliminate the extra 41 major faults to restore working set
> > > of zsh etc.)
> >
> > I'm surprised this.
> > Why your patch don't protect mapped page from streaming io?
>
> I guess you use initlevel=5 and use only terminal, right?
> if so, dropping some graphics component makes sense.
No, it's in pure console mode, no X running at all.
>
> >
> > I strongly hope reproduce myself, please teach me reproduce way.
>
>
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 4:41 ` KOSAKI Motohiro
2009-05-19 4:44 ` KOSAKI Motohiro
@ 2009-05-19 5:09 ` Wu Fengguang
2009-05-19 6:27 ` Wu Fengguang
2009-05-19 6:25 ` Wu Fengguang
2009-05-19 7:15 ` Wu Fengguang
3 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 5:09 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
[-- Attachment #1: Type: text/plain, Size: 4860 bytes --]
On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> Hi
>
> Thanks for great works.
>
>
> > SUMMARY
> > =======
> > The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
> >
> >
> > SCENARIO
> > ========
> > The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> > where 10% of the pages will be activated:
> >
> > for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> > iotrace.rb --load pattern-hot-10 --play /b/sparse
>
>
> Which can I download iotrace.rb?
In the attachment. It relies on some ruby libraries.
> > and monitor /proc/vmstat during the time. The test box has 2G memory.
> >
> >
> > ANALYZES
> > ========
> >
> > I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> > patch, and fetched the vmstat numbers on
> >
> > (1) begin: shortly after the big read IO starts;
> > (2) end: just before the big read IO stops;
> > (3) restore: the big read IO stops and the zsh working set restored
> >
> > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> > begin: 2481 2237 8694 630 0 574299
> > end: 275 231976 233914 633 776271 20933042
> > restore: 370 232154 234524 691 777183 20958453
> >
> > begin: 2434 2237 8493 629 0 574195
> > end: 284 231970 233536 632 771918 20896129
> > restore: 399 232218 234789 690 774526 20957909
> >
> > and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
>
> I don't think it is proper comparision.
> you need either following comparision. otherwise we insert many guess into the analysis.
>
> - 2.6.29 with and without VM_EXEC patch
> - 2.6.30-rc4-mm with and without VM_EXEC patch
I think it doesn't matter that much when it comes to "relative" numbers.
But anyway I guess you want to try a more typical desktop ;)
Unfortunately currently the Xorg is broken in my test box..
> >
> > begin: 2479 2344 9659 210 0 579643
> > end: 284 232010 234142 260 772776 20917184
> > restore: 379 232159 234371 301 774888 20967849
> >
> > The numbers show that
> >
> > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > I'd attribute that improvement to the mmap readahead improvements :-)
> >
> > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > That's a huge improvement - which means with the VM_EXEC protection logic,
> > active mmap pages is pretty safe even under partially cache hot streaming IO.
> >
> > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > That roughly means the active mmap pages get 20.8 more chances to get
> > re-referenced to stay in memory.
> >
> > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > dropped pages are mostly inactive ones. The patch has almost no impact in
> > this aspect, that means it won't unnecessarily increase memory pressure.
> > (In contrast, your 20% mmap protection ratio will keep them all, and
> > therefore eliminate the extra 41 major faults to restore working set
> > of zsh etc.)
>
> I'm surprised this.
> Why your patch don't protect mapped page from streaming io?
It is only protecting the *active* mapped pages, as expected.
But yes, the active percent is much lower than expected :-)
> I strongly hope reproduce myself, please teach me reproduce way.
OK.
Firstly:
for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
dd if=/dev/zero of=/tmp/sparse bs=1M count=1 seek=1024000
Then boot into desktop and run concurrently:
iotrace.rb --load pattern-hot-10 --play /tmp/sparse
vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
Note that I was creating the sparse file in btrfs, which happens to be
very slow in sparse file reading:
151.194384MB/s 284.198252s 100001x 450560b --load pattern-hot-10 --play /b/sparse
In that case, the inactive list is rotated at the speed of 250MB/s,
so a full scan of which takes about 3.5 seconds, while a full scan
of active file list takes about 77 seconds.
Attached source code for both of the above tools.
Thanks,
Fengguang
[-- Attachment #2: iotrace.rb --]
[-- Type: application/x-ruby, Size: 8999 bytes --]
[-- Attachment #3: vmmon.c --]
[-- Type: text/x-csrc, Size: 2410 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/time.h>
static int raw = 1;
static int delay = 1;
static int nr_fields;
static char **fields;
static FILE *f;
static void acquire(long *values)
{
char buf[1024];
rewind(f);
memset(values, 0, nr_fields * sizeof(*values));
while (fgets(buf, sizeof(buf), f)) {
int i;
for (i = 0; i < nr_fields; i++) {
char *p;
if (strncmp(buf, fields[i], strlen(fields[i])))
continue;
p = strchr(buf, ' ');
if (p == NULL) {
fprintf(stderr, "vmmon: error parsing /proc\n");
exit(1);
}
values[i] += strtoul(p, NULL, 10);
break;
}
}
}
static void display(long *new_values, long *prev_values,
unsigned long long usecs)
{
int i;
for (i = 0; i < nr_fields; i++) {
if (raw)
printf(" %16ld", new_values[i]);
else {
long long diff;
double ddiff;
ddiff = new_values[i] - prev_values[i];
ddiff *= 1000000;
ddiff /= usecs;
diff = ddiff;
printf(" %16lld", diff);
}
}
printf("\n");
}
static void do1(long *prev_values)
{
struct timeval start;
struct timeval end;
long long usecs;
long new_values[nr_fields];
gettimeofday(&start, NULL);
sleep(delay);
gettimeofday(&end, NULL);
acquire(new_values);
usecs = end.tv_sec - start.tv_sec;
usecs *= 1000000;
usecs += end.tv_usec - start.tv_usec;
display(new_values, prev_values, usecs);
memcpy(prev_values, new_values, nr_fields * sizeof(*prev_values));
}
static void heading(void)
{
int i;
printf("\n");
for (i = 0; i < nr_fields; i++)
printf(" %16s", fields[i]);
printf("\n");
}
static void doit(void)
{
int line = 0;
long prev_values[nr_fields];
acquire(prev_values);
for ( ; ; ) {
if (line == 0)
heading();
do1(prev_values);
line++;
if (line == 24)
line = 0;
}
}
static void usage(void)
{
fprintf(stderr, "usage: vmmon [-r] [-d N] field [field ...]\n");
fprintf(stderr, " -d N : delay N seconds\n");
fprintf(stderr, " -r : show raw numbers instead of diff\n");
exit(1);
}
int main(int argc, char *argv[])
{
int c;
while ((c = getopt(argc, argv, "rd:")) != -1) {
switch (c) {
case 'r':
raw = 1;
case 'd':
delay = strtol(optarg, NULL, 10);
break;
default:
usage();
}
}
if (optind == argc)
usage();
nr_fields = argc - optind;
fields = argv + optind;
f = fopen("/proc/vmstat", "r");
doit();
exit(0);
}
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 5:09 ` Wu Fengguang
@ 2009-05-19 6:27 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 6:27 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 01:09:32PM +0800, Wu Fengguang wrote:
> On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> Note that I was creating the sparse file in btrfs, which happens to be
> very slow in sparse file reading:
>
> 151.194384MB/s 284.198252s 100001x 450560b --load pattern-hot-10 --play /b/sparse
>
> In that case, the inactive list is rotated at the speed of 250MB/s,
> so a full scan of which takes about 3.5 seconds, while a full scan
> of active file list takes about 77 seconds.
Hi KOSAKI: you can limit the read speed with iotrace.rb's
"--think-time" option, or to read the sparse file over network.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 4:41 ` KOSAKI Motohiro
2009-05-19 4:44 ` KOSAKI Motohiro
2009-05-19 5:09 ` Wu Fengguang
@ 2009-05-19 6:25 ` Wu Fengguang
2009-05-20 11:20 ` Andi Kleen
2009-05-19 7:15 ` Wu Fengguang
3 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 6:25 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> Hi
>
> Thanks for great works.
>
>
> > SUMMARY
> > =======
> > The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
> >
> >
> > SCENARIO
> > ========
> > The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> > where 10% of the pages will be activated:
> >
> > for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> > iotrace.rb --load pattern-hot-10 --play /b/sparse
>
>
> Which can I download iotrace.rb?
>
>
> > and monitor /proc/vmstat during the time. The test box has 2G memory.
> >
> >
> > ANALYZES
> > ========
> >
> > I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> > patch, and fetched the vmstat numbers on
> >
> > (1) begin: shortly after the big read IO starts;
> > (2) end: just before the big read IO stops;
> > (3) restore: the big read IO stops and the zsh working set restored
> >
> > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> > begin: 2481 2237 8694 630 0 574299
> > end: 275 231976 233914 633 776271 20933042
> > restore: 370 232154 234524 691 777183 20958453
> >
> > begin: 2434 2237 8493 629 0 574195
> > end: 284 231970 233536 632 771918 20896129
> > restore: 399 232218 234789 690 774526 20957909
> >
> > and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
>
> I don't think it is proper comparision.
> you need either following comparision. otherwise we insert many guess into the analysis.
>
> - 2.6.29 with and without VM_EXEC patch
> - 2.6.30-rc4-mm with and without VM_EXEC patch
OK, here is the comparison on 2.6.30-rc4-mm with VM_EXEC logic disabled/enabled.
2.6.30-rc4-mm, VM_EXEC protection OFF
-------------------------------------
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
begin: 2479 2344 9659 210 0 579643
end: 284 232010 234142 260 772776 20917184
restore: 379 232159 234371 301 774888 20967849
2.6.30-rc4-mm, VM_EXEC protection ON
------------------------------------
begin: 2444 6652 50021 207 0 619959
end: 284 231752 233394 210 773879 20890132
restore: 399 231973 234352 251 776879 20960568
We can reach basically the same conclusion from the above data.
Thanks,
Fengguang
---
raw data for the 2.6.30-rc4-mm VM_EXEC ON case:
% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2250 2291 9013 200 0 573898
2250 2291 9013 200 0 573900
2250 2291 9013 200 0 573913
2437 2291 9327 207 0 574340
2441 2291 9517 207 0 574342
2441 2880 15925 207 0 579328
2444 6652 50021 207 0 619959
2444 10392 84169 207 0 660463
2444 14132 117262 207 0 702806
2444 17934 151968 207 0 743335
2444 21714 186052 207 0 783837
2444 25505 220606 207 0 824341
2444 29284 254297 207 0 866686
2444 33157 288730 207 0 907190
2444 36917 322858 207 0 949533
2444 40809 357878 207 0 990043
2444 44547 391997 207 0 1030545
2444 48368 421647 207 2464 1077033
2444 53199 415457 207 4032 1146417
2444 56723 412522 207 5312 1220349
2444 60233 409352 207 5312 1293510
2444 63755 404683 207 5312 1366553
2444 67336 401214 207 5312 1440753
2444 70869 397266 207 5312 1515153
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2444 74450 394610 207 5312 1588258
2444 77958 391189 207 5312 1662693
2444 81519 387134 207 5312 1737203
2444 85081 383314 207 5312 1811529
2444 88591 379561 207 5312 1885074
2444 92161 376554 207 5312 1960083
2444 95452 372158 207 5312 2033133
2444 98925 369920 207 5312 2106356
2444 102187 366606 207 5312 2179896
2444 105737 362151 207 5312 2252653
2444 109257 358798 207 5312 2326643
2444 112859 355582 207 5312 2400045
2444 116318 352572 207 5312 2474330
2444 119890 347888 207 5312 2548928
2444 123419 344722 207 5312 2621237
2444 127001 341163 207 5312 2695899
2444 130553 336876 207 5312 2770178
2444 134052 334230 207 5312 2842983
2444 137553 330367 207 5312 2915827
2444 141094 327120 207 5312 2988966
2444 144502 323269 207 5312 3061070
2444 148075 319689 207 5312 3135630
2444 151649 315738 207 5312 3209493
2444 155219 312595 207 5312 3283546
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2444 158728 308908 207 5312 3357537
2444 162216 305892 207 5312 3431238
2444 165759 301320 207 5312 3503900
2444 169268 298617 207 5312 3577602
2444 172748 294222 207 5312 3650985
2444 176290 290673 207 5312 3723645
2444 179823 287268 207 5312 3796933
2444 183301 283988 207 5312 3870730
2444 186843 279829 207 5312 3943552
2444 190426 276280 207 5312 4018059
2444 193955 273202 207 5312 4090994
2444 197383 269182 207 5312 4164812
2444 200904 265426 207 5312 4237489
2444 204375 261999 207 5312 4310454
2444 207875 258741 207 5312 4382745
2444 211367 255351 207 5312 4455714
2444 214876 251224 207 5312 4528503
2444 218408 247664 207 5312 4602332
2444 221906 244700 207 5312 4675462
2444 225419 240555 207 5312 4748250
2444 228856 237982 207 5312 4820833
2444 232143 233737 207 5550 4893429
2444 232128 233872 207 9114 4966779
2444 232078 234631 207 12642 5040609
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2444 231981 233576 207 16258 5113398
2444 231999 234358 207 19794 5186057
2444 231923 233510 207 23290 5258642
2444 231858 234035 207 26786 5331127
2426 231846 233471 207 30338 5403852
2426 231937 234323 207 33770 5476403
2426 231766 233470 207 37418 5550924
2426 231826 233872 207 40906 5623180
2426 231813 234446 207 44362 5696097
2426 231771 233369 207 47938 5768853
2426 231766 234365 207 51410 5841381
2426 231667 233473 207 54996 5914049
2426 231777 233364 207 58452 5988563
2426 231777 234418 207 61980 6061034
2426 231791 234341 207 65460 6135636
2426 231703 233374 207 69076 6208350
2426 231764 233762 207 72564 6281377
1769 231746 233342 207 76004 6353551
1104 231654 233722 207 79676 6427765
1104 231557 233789 207 83332 6502311
1104 231836 234211 207 86588 6575126
1104 231668 233772 207 90212 6649213
1104 231545 233735 207 93884 6722035
1104 231700 233686 207 97212 6794403
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1104 231595 233749 207 100804 6867099
1104 231471 233649 207 104508 6941830
1104 231688 234647 207 107764 7014098
1104 231567 233713 207 111372 7086796
1104 231453 233667 207 115076 7161462
1104 231638 234665 207 118364 7233770
1104 231461 233659 207 122028 7306593
1104 231731 233324 207 125324 7380134
1104 231642 234630 207 128900 7453391
1104 231459 233629 207 132580 7527753
1104 231769 233350 207 135836 7601530
1104 231670 233833 207 139484 7673804
1104 231822 234320 207 142836 7746650
1104 231703 233352 207 146452 7819376
1104 231628 233907 207 150076 7893367
1104 231780 234362 207 153428 7966268
1104 231749 234316 207 156964 8040835
1104 231745 233343 207 160516 8113464
1104 231679 233889 207 164100 8187486
1104 231593 234422 207 167652 8260483
1104 231712 233312 207 171068 8333148
1104 231645 233795 207 174684 8407233
1104 231836 234275 207 178028 8480039
1104 231716 233308 207 181604 8552764
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1104 231618 233726 207 185292 8626946
1104 231843 234268 207 188540 8699655
1104 231674 233734 207 192196 8772013
1104 231662 233746 207 195788 8846514
1104 231892 233620 207 199124 8919860
1104 231616 233728 207 202804 8991883
1104 231549 233699 207 206420 9066293
1104 231757 234610 207 209716 9138618
1104 231620 233724 207 213340 9212822
1104 231499 233653 207 217020 9286005
1104 231660 234739 207 220332 9358235
1104 231587 233661 207 223892 9431023
1104 231505 233615 207 227564 9505653
1104 231650 234685 207 230892 9577914
1104 231497 233623 207 234532 9650768
1104 231574 233163 207 238035 9724587
1104 231639 234696 207 241443 9797531
1104 231480 233640 207 245099 9870384
1104 231726 233329 207 248419 9943926
1104 231621 234618 207 252011 10017243
1104 231420 233540 207 255699 10090161
1104 231638 233642 207 258923 10162294
284 231494 233594 207 262595 10235150
275 231687 234616 207 265875 10307412
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231454 233698 207 269595 10380201
275 231655 234744 207 272867 10452430
275 231574 233738 207 276435 10525155
275 231726 234737 207 279787 10597480
275 231546 233766 207 283433 10670269
275 231666 233295 207 286893 10744085
275 231675 233637 207 290357 10817230
275 231554 233726 207 293965 10889960
275 231696 233297 207 297413 10963738
275 231548 233764 207 300941 11035910
275 231536 233648 207 304533 11109697
275 231713 234718 207 307829 11181942
275 231600 233744 207 311429 11254679
275 231494 233690 207 315125 11329352
275 231781 234074 207 318373 11402151
275 231542 233706 207 322037 11476281
275 231796 233387 207 325349 11548003
275 231706 234629 207 328957 11621381
275 231503 233692 207 332637 11695235
275 231789 233373 207 335917 11767682
275 231730 233848 207 339525 11841744
275 231858 234327 207 342901 11914649
275 231785 233409 207 346461 11988352
275 231602 234616 207 350141 12060761
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231810 234375 207 353437 12134278
275 231775 233419 207 357021 12206908
275 231926 233941 207 360405 12280740
275 231823 234393 207 364005 12353897
275 231662 233532 207 367653 12426715
275 231812 233991 207 371069 12500421
275 231804 234349 207 374533 12573548
275 231795 233400 207 378077 12646144
275 231729 233946 207 381661 12720171
275 231707 234511 207 385149 12793073
275 231786 233377 207 388605 12866206
275 231711 233932 207 392229 12939820
275 231870 234348 207 395605 13012722
275 231766 233365 207 399165 13085459
275 231661 233790 207 402829 13159645
275 231884 234270 207 406141 13232418
275 231763 233784 207 409749 13306504
275 231696 233787 207 413365 13379233
275 231950 233756 207 416677 13452487
275 231741 233785 207 420269 13524912
275 231615 233740 207 423965 13598978
275 231847 234691 207 427237 13671267
275 231709 233806 207 430893 13745773
275 231549 233678 207 434581 13818721
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231827 233943 207 437869 13891638
275 231653 233798 207 441437 13965122
275 231555 233768 207 445125 14038243
275 231740 234766 207 448413 14110536
275 231587 233704 207 452053 14183389
275 231471 233660 207 455749 14258050
275 231751 234659 207 458973 14330216
275 231545 233682 207 462645 14403068
275 231799 233395 207 465957 14476579
275 231625 233730 207 469556 14549896
275 231486 233677 207 473244 14622749
275 231733 234133 207 476532 14695505
275 231528 233699 207 480172 14769641
275 231766 233396 207 483500 14841341
275 231662 233629 207 487060 14914691
275 231476 233719 207 490764 14987447
275 231647 233740 207 494004 15059709
275 231478 233717 207 497732 15132562
275 231680 233771 207 500972 15204760
275 231590 233797 207 504580 15277497
275 231735 234771 207 507908 15349860
275 231566 233725 207 511564 15422712
275 231840 234570 207 514794 15495070
275 231677 233813 207 518430 15567636
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231892 234006 207 521774 15640698
275 231653 233766 207 525438 15712814
275 231586 233801 207 529054 15787349
275 231811 234760 207 532302 15859611
275 231672 233780 207 535958 15932401
275 231822 234365 207 539270 16005142
275 231739 233360 207 542862 16077868
275 231837 233428 207 546318 16151136
275 231683 233768 207 549878 16222632
275 231551 233841 207 553574 16297201
275 231827 234327 207 556766 16369911
275 231713 233786 207 560382 16442191
275 231888 234281 207 563710 16515003
275 231715 233818 207 567374 16587315
275 231664 233819 207 570966 16661855
275 231795 234346 207 574326 16734662
275 231618 233844 207 577982 16806982
275 231606 233717 207 581574 16881646
275 231802 234310 207 584862 16954315
275 231633 233797 207 588518 17026659
275 231597 233769 207 592134 17101225
275 231734 234687 207 595470 17173647
275 231607 233727 207 599094 17246374
275 231491 233651 207 602790 17321067
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231748 233746 207 606006 17393169
275 231483 233723 207 609758 17466136
275 231708 234745 207 613006 17538366
275 231621 233809 207 616590 17611026
275 231481 233661 207 620310 17685821
275 231738 234779 207 623526 17757922
275 231561 233805 207 627190 17830711
275 231871 233686 207 630446 17903980
275 231595 233739 207 634126 17975859
275 231495 233743 207 637806 18050456
275 231822 234151 207 641014 18123181
275 231535 233735 207 644726 18196609
275 231805 233400 207 648022 18269081
275 231646 234679 207 651678 18342463
275 231501 233673 207 655310 18415252
275 231795 233410 207 658582 18488697
275 231619 233651 207 662214 18562111
275 231811 233394 207 665526 18634440
275 231714 234227 207 669182 18707545
275 231443 233603 207 672878 18781620
275 231793 233412 207 676094 18853428
275 231680 233654 207 679694 18926777
275 231778 233380 207 683086 18998607
275 231768 233949 207 686638 19072500
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
275 231513 233725 207 690318 19144649
275 231775 233430 207 693622 19218158
275 231600 233702 207 697222 19291540
275 231768 233405 207 700589 19363304
275 231689 233677 207 704165 19436591
275 231480 233726 207 707861 19509411
275 231766 233535 207 711141 19582761
284 231538 233727 210 714773 19654593
284 231806 233394 210 718061 19728136
284 231602 233695 210 721669 19799676
284 231771 234773 210 724973 19871907
284 231610 233751 210 728621 19944728
284 231779 234349 210 731925 20017438
284 231665 233856 210 735557 20089683
284 231812 234294 210 738861 20162544
284 231692 233838 210 742509 20234788
284 231840 234361 210 745803 20307594
284 231754 233808 210 749407 20379870
284 231812 234421 210 752791 20452676
284 231756 233432 210 756375 20525369
284 231771 234461 210 759847 20597791
284 231780 233398 210 763311 20671332
284 231657 233905 210 766983 20744601
284 231826 234375 210 770287 20817438
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
284 231752 233394 210 773879 20890132
408 231801 234393 246 776879 20959316
399 231973 234352 251 776879 20960036
399 231973 234352 251 776879 20960036
399 231973 234352 251 776879 20960201
399 231973 234352 251 776879 20960201
399 231973 234352 251 776879 20960202
399 231973 234352 251 776879 20960435
399 231973 234352 251 776879 20960436
399 231973 234352 251 776879 20960436
399 231973 234352 251 776879 20960525
399 231973 234352 251 776879 20960525
399 231973 234352 251 776879 20960539
399 231973 234352 251 776879 20960548
399 231973 234352 251 776879 20960550
399 231973 234352 251 776879 20960550
399 231973 234352 251 776879 20960554
399 231973 234352 251 776879 20960554
399 231973 234352 251 776879 20960555
399 231973 234352 251 776879 20960562
399 231973 234352 251 776879 20960562
399 231973 234352 251 776879 20960563
399 231973 234352 251 776879 20960567
399 231973 234352 251 776879 20960568
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 6:25 ` Wu Fengguang
@ 2009-05-20 11:20 ` Andi Kleen
2009-05-20 14:32 ` Wu Fengguang
2009-06-08 7:39 ` Wu Fengguang
0 siblings, 2 replies; 69+ messages in thread
From: Andi Kleen @ 2009-05-20 11:20 UTC (permalink / raw)
To: Wu Fengguang
Cc: KOSAKI Motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
Wu Fengguang <fengguang.wu@intel.com> writes:
>
> 2.6.30-rc4-mm, VM_EXEC protection ON
> ------------------------------------
> begin: 2444 6652 50021 207 0 619959
> end: 284 231752 233394 210 773879 20890132
> restore: 399 231973 234352 251 776879 20960568
>
> We can reach basically the same conclusion from the above data.
One scenario that might be useful to test is what happens when some very large
processes, all mapped and executable exceed memory and fight each other
for the working set. Do you have regressions then compared to without
the patches?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 11:20 ` Andi Kleen
@ 2009-05-20 14:32 ` Wu Fengguang
2009-05-20 14:47 ` Andi Kleen
2009-06-08 7:39 ` Wu Fengguang
1 sibling, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-20 14:32 UTC (permalink / raw)
To: Andi Kleen
Cc: KOSAKI Motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
> Wu Fengguang <fengguang.wu@intel.com> writes:
> >
> > 2.6.30-rc4-mm, VM_EXEC protection ON
> > ------------------------------------
> > begin: 2444 6652 50021 207 0 619959
> > end: 284 231752 233394 210 773879 20890132
> > restore: 399 231973 234352 251 776879 20960568
> >
> > We can reach basically the same conclusion from the above data.
>
> One scenario that might be useful to test is what happens when some
> very large processes, all mapped and executable exceed memory and
Good idea. Too bad I may have to install some bloated desktop in order
to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
negative scores in that case?
> fight each other for the working set. Do you have regressions then
> compared to without the patches?
No regressions for the above test. IMHO it can hardly create
regressions if there are no one to aggressively abuse it. Rik and
Christoph's ratio based logics are more likely to achieve better
protections as well as regressions.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 14:32 ` Wu Fengguang
@ 2009-05-20 14:47 ` Andi Kleen
2009-05-20 14:56 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Andi Kleen @ 2009-05-20 14:47 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andi Kleen, KOSAKI Motohiro, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
> > One scenario that might be useful to test is what happens when some
> > very large processes, all mapped and executable exceed memory and
>
> Good idea. Too bad I may have to install some bloated desktop in order
> to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
> negative scores in that case?
I would just generate a large C program with a script and compile
and run that. The program can be very dumb (e.g. only run
a gigantic loop), it just needs to be large.
Just don't compile it with optimization, that can be quite slow.
And use multiple functions, otherwise gcc might exceed your memory.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 14:47 ` Andi Kleen
@ 2009-05-20 14:56 ` Wu Fengguang
2009-05-20 15:38 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-20 14:56 UTC (permalink / raw)
To: Andi Kleen
Cc: KOSAKI Motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote:
> > > One scenario that might be useful to test is what happens when some
> > > very large processes, all mapped and executable exceed memory and
> >
> > Good idea. Too bad I may have to install some bloated desktop in order
> > to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
> > negative scores in that case?
>
> I would just generate a large C program with a script and compile
> and run that. The program can be very dumb (e.g. only run
> a gigantic loop), it just needs to be large.
>
> Just don't compile it with optimization, that can be quite slow.
>
> And use multiple functions, otherwise gcc might exceed your memory.
Hehe, an arbitrary C program may not be persuasive..but I do have some
bloated binaries at hand :-)
-rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg
lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X -> Xorg
-rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb
-rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 14:56 ` Wu Fengguang
@ 2009-05-20 15:38 ` Wu Fengguang
2009-06-08 12:14 ` Nai Xia
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-20 15:38 UTC (permalink / raw)
To: gnome-list
Cc: Andi Kleen, KOSAKI Motohiro, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com, xorg@lists.freedesktop.org
Hi list,
On Wed, May 20, 2009 at 10:56:07PM +0800, Wu Fengguang wrote:
> On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote:
> > > > One scenario that might be useful to test is what happens when some
> > > > very large processes, all mapped and executable exceed memory and
> > >
> > > Good idea. Too bad I may have to install some bloated desktop in order
> > > to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
> > > negative scores in that case?
> >
> > I would just generate a large C program with a script and compile
> > and run that. The program can be very dumb (e.g. only run
> > a gigantic loop), it just needs to be large.
> >
> > Just don't compile it with optimization, that can be quite slow.
> >
> > And use multiple functions, otherwise gcc might exceed your memory.
>
>
> Hehe, an arbitrary C program may not be persuasive..but I do have some
> bloated binaries at hand :-)
>
> -rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg
> lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X -> Xorg
> -rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb
> -rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest
I would like to create a lot of windows in gnome, and to switch
between them. Any ideas on scripting/automating the "switch window"
actions?
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 15:38 ` Wu Fengguang
@ 2009-06-08 12:14 ` Nai Xia
2009-06-08 12:46 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Nai Xia @ 2009-06-08 12:14 UTC (permalink / raw)
To: Wu Fengguang
Cc: gnome-list, Andi Kleen, KOSAKI Motohiro, Christoph Lameter,
Andrew Morton, LKML, Elladan, Nick Piggin, Johannes Weiner,
Peter Zijlstra, Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com, xorg@lists.freedesktop.org
On Wed, May 20, 2009 at 11:38 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
> Hi list,
>
> On Wed, May 20, 2009 at 10:56:07PM +0800, Wu Fengguang wrote:
>> On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote:
>> > > > One scenario that might be useful to test is what happens when some
>> > > > very large processes, all mapped and executable exceed memory and
>> > >
>> > > Good idea. Too bad I may have to install some bloated desktop in order
>> > > to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
>> > > negative scores in that case?
>> >
>> > I would just generate a large C program with a script and compile
>> > and run that. The program can be very dumb (e.g. only run
>> > a gigantic loop), it just needs to be large.
>> >
>> > Just don't compile it with optimization, that can be quite slow.
>> >
>> > And use multiple functions, otherwise gcc might exceed your memory.
>>
>>
>> Hehe, an arbitrary C program may not be persuasive..but I do have some
>> bloated binaries at hand :-)
>>
>> -rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg
>> lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X -> Xorg
>> -rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb
>> -rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest
>
> I would like to create a lot of windows in gnome, and to switch
> between them. Any ideas on scripting/automating the "switch window"
> actions?
You can easily do this in KDE 3.5 with dcop(Desktop Communications Protocol)\
e.g.
$dcop kchmviewer-17502 KCHMMainWindow raise
will raise the window of my kchmviewer.
>
> Thanks,
> Fengguang
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 12:14 ` Nai Xia
@ 2009-06-08 12:46 ` Wu Fengguang
2009-06-08 15:02 ` Nai Xia
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-06-08 12:46 UTC (permalink / raw)
To: Nai Xia
Cc: gnome-list@gnome.org, Andi Kleen, KOSAKI Motohiro,
Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com,
xorg@lists.freedesktop.org
On Mon, Jun 08, 2009 at 08:14:53PM +0800, Nai Xia wrote:
> On Wed, May 20, 2009 at 11:38 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
> > Hi list,
> >
> > On Wed, May 20, 2009 at 10:56:07PM +0800, Wu Fengguang wrote:
> >> On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote:
> >> > > > One scenario that might be useful to test is what happens when some
> >> > > > very large processes, all mapped and executable exceed memory and
> >> > >
> >> > > Good idea. Too bad I may have to install some bloated desktop in order
> >> > > to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
> >> > > negative scores in that case?
> >> >
> >> > I would just generate a large C program with a script and compile
> >> > and run that. The program can be very dumb (e.g. only run
> >> > a gigantic loop), it just needs to be large.
> >> >
> >> > Just don't compile it with optimization, that can be quite slow.
> >> >
> >> > And use multiple functions, otherwise gcc might exceed your memory.
> >>
> >>
> >> Hehe, an arbitrary C program may not be persuasive..but I do have some
> >> bloated binaries at hand :-)
> >>
> >> -rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg
> >> lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X -> Xorg
> >> -rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb
> >> -rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest
> >
> > I would like to create a lot of windows in gnome, and to switch
> > between them. Any ideas on scripting/automating the "switch window"
> > actions?
>
> You can easily do this in KDE 3.5 with dcop(Desktop Communications Protocol)\
>
> e.g.
>
> $dcop kchmviewer-17502 KCHMMainWindow raise
>
> will raise the window of my kchmviewer.
Thank you, it's a good tip :)
The alternative I found is wmctrl:
Description: control an EWMH/NetWM compatible X Window Manager
Wmctrl is a command line tool to interact with an
EWMH/NetWM compatible X Window Manager (examples include
Enlightenment, icewm, kwin, metacity, and sawfish).
.
Wmctrl provides command line access to almost all the features
defined in the EWMH specification. For example it can maximize
windows, make them sticky, set them to be always on top. It can
switch and resize desktops and perform many other useful
operations.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 12:46 ` Wu Fengguang
@ 2009-06-08 15:02 ` Nai Xia
0 siblings, 0 replies; 69+ messages in thread
From: Nai Xia @ 2009-06-08 15:02 UTC (permalink / raw)
To: Wu Fengguang
Cc: gnome-list@gnome.org, Andi Kleen, KOSAKI Motohiro,
Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com,
xorg@lists.freedesktop.org
On Mon, Jun 8, 2009 at 8:46 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
> On Mon, Jun 08, 2009 at 08:14:53PM +0800, Nai Xia wrote:
>> On Wed, May 20, 2009 at 11:38 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
>> > Hi list,
>> >
>> > On Wed, May 20, 2009 at 10:56:07PM +0800, Wu Fengguang wrote:
>> >> On Wed, May 20, 2009 at 10:47:31PM +0800, Andi Kleen wrote:
>> >> > > > One scenario that might be useful to test is what happens when some
>> >> > > > very large processes, all mapped and executable exceed memory and
>> >> > >
>> >> > > Good idea. Too bad I may have to install some bloated desktop in order
>> >> > > to test this out ;) I guess the pgmajfault+pswpin numbers can serve as
>> >> > > negative scores in that case?
>> >> >
>> >> > I would just generate a large C program with a script and compile
>> >> > and run that. The program can be very dumb (e.g. only run
>> >> > a gigantic loop), it just needs to be large.
>> >> >
>> >> > Just don't compile it with optimization, that can be quite slow.
>> >> >
>> >> > And use multiple functions, otherwise gcc might exceed your memory.
>> >>
>> >>
>> >> Hehe, an arbitrary C program may not be persuasive..but I do have some
>> >> bloated binaries at hand :-)
>> >>
>> >> -rwsr-sr-x 1 root wfg 36M 2009-04-22 17:21 Xorg
>> >> lrwxrwxrwx 1 wfg wfg 4 2009-04-22 17:21 X -> Xorg
>> >> -rwxr-xr-x 1 wfg wfg 39M 2009-04-22 17:21 Xvfb
>> >> -rwxr-xr-x 1 wfg wfg 35M 2009-04-22 17:21 Xnest
>> >
>> > I would like to create a lot of windows in gnome, and to switch
>> > between them. Any ideas on scripting/automating the "switch window"
>> > actions?
>>
>> You can easily do this in KDE 3.5 with dcop(Desktop Communications Protocol)\
>>
>> e.g.
>>
>> $dcop kchmviewer-17502 KCHMMainWindow raise
>>
>> will raise the window of my kchmviewer.
>
> Thank you, it's a good tip :)
>
> The alternative I found is wmctrl:
>
> Description: control an EWMH/NetWM compatible X Window Manager
> Wmctrl is a command line tool to interact with an
> EWMH/NetWM compatible X Window Manager (examples include
> Enlightenment, icewm, kwin, metacity, and sawfish).
> .
> Wmctrl provides command line access to almost all the features
> defined in the EWMH specification. For example it can maximize
> windows, make them sticky, set them to be always on top. It can
> switch and resize desktops and perform many other useful
> operations.
Cool, thanks for the information. :)
BTW, may be you should make sure that 90% of the overhead
when doing crazy window switches is NOT caused by a dumb graphics
driver (e.g. the widely hated ATI official driver!). hehe
>
> Thanks,
> Fengguang
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 11:20 ` Andi Kleen
2009-05-20 14:32 ` Wu Fengguang
@ 2009-06-08 7:39 ` Wu Fengguang
2009-06-08 7:51 ` KOSAKI Motohiro
2009-06-08 17:18 ` Nai Xia
1 sibling, 2 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-06-08 7:39 UTC (permalink / raw)
To: Andi Kleen
Cc: KOSAKI Motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
> One scenario that might be useful to test is what happens when some very large
> processes, all mapped and executable exceed memory and fight each other
> for the working set. Do you have regressions then compared to without
> the patches?
I managed to carry out some stress tests for memory tight desktops.
The outcome is encouraging: clock time and major faults are reduced
by 50%, and pswpin numbers are reduced to ~1/3.
Here is the test scenario.
- nfsroot gnome desktop with 512M physical memory
- run some programs, and switch between the existing windows after
starting each new program.
The progress timing (seconds) is:
before after programs
0.02 0.02 N xeyes
0.75 0.76 N firefox
2.02 1.88 N nautilus
3.36 3.17 N nautilus --browser
5.26 4.89 N gthumb
7.12 6.47 N gedit
9.22 8.16 N xpdf /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf
13.58 12.55 N xterm
15.87 14.57 N mlterm
18.63 17.06 N gnome-terminal
21.16 18.90 N urxvt
26.24 23.48 N gnome-system-monitor
28.72 26.52 N gnome-help
32.15 29.65 N gnome-dictionary
39.66 36.12 N /usr/games/sol
43.16 39.27 N /usr/games/gnometris
48.65 42.56 N /usr/games/gnect
53.31 47.03 N /usr/games/gtali
58.60 52.05 N /usr/games/iagno
65.77 55.42 N /usr/games/gnotravex
70.76 61.47 N /usr/games/mahjongg
76.15 67.11 N /usr/games/gnome-sudoku
86.32 75.15 N /usr/games/glines
92.21 79.70 N /usr/games/glchess
103.79 88.48 N /usr/games/gnomine
113.84 96.51 N /usr/games/gnotski
124.40 102.19 N /usr/games/gnibbles
137.41 114.93 N /usr/games/gnobots2
155.53 125.02 N /usr/games/blackjack
179.85 135.11 N /usr/games/same-gnome
224.49 154.50 N /usr/bin/gnome-window-properties
248.44 162.09 N /usr/bin/gnome-default-applications-properties
282.62 173.29 N /usr/bin/gnome-at-properties
323.72 188.21 N /usr/bin/gnome-typing-monitor
363.99 199.93 N /usr/bin/gnome-at-visual
394.21 206.95 N /usr/bin/gnome-sound-properties
435.14 224.49 N /usr/bin/gnome-at-mobility
463.05 234.11 N /usr/bin/gnome-keybinding-properties
503.75 248.59 N /usr/bin/gnome-about-me
554.00 276.27 N /usr/bin/gnome-display-properties
615.48 304.39 N /usr/bin/gnome-network-preferences
693.03 342.01 N /usr/bin/gnome-mouse-properties
759.90 388.58 N /usr/bin/gnome-appearance-properties
937.90 508.47 N /usr/bin/gnome-control-center
1109.75 587.57 N /usr/bin/gnome-keyboard-properties
1399.05 758.16 N : oocalc
1524.64 830.03 N : oodraw
1684.31 900.03 N : ooimpress
1874.04 993.91 N : oomath
2115.12 1081.89 N : ooweb
2369.02 1161.99 N : oowriter
Note that the oo* commands are actually commented out.
The vmstat numbers are (some relevant ones are marked with *):
before after
nr_free_pages 1293 3898
nr_inactive_anon 59956 53460
nr_active_anon 26815 30026
nr_inactive_file 2657 3218
nr_active_file 2019 2806
nr_unevictable 4 4
nr_mlock 4 4
nr_anon_pages 26706 27859
*nr_mapped 3542 4469
nr_file_pages 72232 67681
nr_dirty 1 0
nr_writeback 123 19
nr_slab_reclaimable 3375 3534
nr_slab_unreclaimable 11405 10665
nr_page_table_pages 8106 7864
nr_unstable 0 0
nr_bounce 0 0
*nr_vmscan_write 394776 230839
nr_writeback_temp 0 0
numa_hit 6843353 3318676
numa_miss 0 0
numa_foreign 0 0
numa_interleave 1719 1719
numa_local 6843353 3318676
numa_other 0 0
*pgpgin 5954683 2057175
*pgpgout 1578276 922744
*pswpin 1486615 512238
*pswpout 394568 230685
pgalloc_dma 277432 56602
pgalloc_dma32 6769477 3310348
pgalloc_normal 0 0
pgalloc_movable 0 0
pgfree 7048396 3371118
pgactivate 2036343 1471492
pgdeactivate 2189691 1612829
pgfault 3702176 3100702
*pgmajfault 452116 201343
pgrefill_dma 12185 7127
pgrefill_dma32 334384 653703
pgrefill_normal 0 0
pgrefill_movable 0 0
pgsteal_dma 74214 22179
pgsteal_dma32 3334164 1638029
pgsteal_normal 0 0
pgsteal_movable 0 0
pgscan_kswapd_dma 1081421 1216199
pgscan_kswapd_dma32 58979118 46002810
pgscan_kswapd_normal 0 0
pgscan_kswapd_movable 0 0
pgscan_direct_dma 2015438 1086109
pgscan_direct_dma32 55787823 36101597
pgscan_direct_normal 0 0
pgscan_direct_movable 0 0
pginodesteal 3461 7281
slabs_scanned 564864 527616
kswapd_steal 2889797 1448082
kswapd_inodesteal 14827 14835
pageoutrun 43459 21562
allocstall 9653 4032
pgrotated 384216 228631
htlb_buddy_alloc_success 0 0
htlb_buddy_alloc_fail 0 0
unevictable_pgs_culled 0 0
unevictable_pgs_scanned 0 0
unevictable_pgs_rescued 0 0
unevictable_pgs_mlocked 4 4
unevictable_pgs_munlocked 0 0
unevictable_pgs_cleared 0 0
unevictable_pgs_stranded 0 0
unevictable_pgs_mlockfreed 0 0
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 7:39 ` Wu Fengguang
@ 2009-06-08 7:51 ` KOSAKI Motohiro
2009-06-08 7:56 ` Wu Fengguang
2009-06-08 17:18 ` Nai Xia
1 sibling, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-06-08 7:51 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Andi Kleen, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
> On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
> > One scenario that might be useful to test is what happens when some very large
> > processes, all mapped and executable exceed memory and fight each other
> > for the working set. Do you have regressions then compared to without
> > the patches?
>
> I managed to carry out some stress tests for memory tight desktops.
> The outcome is encouraging: clock time and major faults are reduced
> by 50%, and pswpin numbers are reduced to ~1/3.
>
> Here is the test scenario.
> - nfsroot gnome desktop with 512M physical memory
> - run some programs, and switch between the existing windows after
> starting each new program.
>
> The progress timing (seconds) is:
>
> before after programs
> 0.02 0.02 N xeyes
> 0.75 0.76 N firefox
> 2.02 1.88 N nautilus
> 3.36 3.17 N nautilus --browser
> 5.26 4.89 N gthumb
> 7.12 6.47 N gedit
> 9.22 8.16 N xpdf /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf
> 13.58 12.55 N xterm
> 15.87 14.57 N mlterm
> 18.63 17.06 N gnome-terminal
> 21.16 18.90 N urxvt
> 26.24 23.48 N gnome-system-monitor
> 28.72 26.52 N gnome-help
> 32.15 29.65 N gnome-dictionary
> 39.66 36.12 N /usr/games/sol
> 43.16 39.27 N /usr/games/gnometris
> 48.65 42.56 N /usr/games/gnect
> 53.31 47.03 N /usr/games/gtali
> 58.60 52.05 N /usr/games/iagno
> 65.77 55.42 N /usr/games/gnotravex
> 70.76 61.47 N /usr/games/mahjongg
> 76.15 67.11 N /usr/games/gnome-sudoku
> 86.32 75.15 N /usr/games/glines
> 92.21 79.70 N /usr/games/glchess
> 103.79 88.48 N /usr/games/gnomine
> 113.84 96.51 N /usr/games/gnotski
> 124.40 102.19 N /usr/games/gnibbles
> 137.41 114.93 N /usr/games/gnobots2
> 155.53 125.02 N /usr/games/blackjack
> 179.85 135.11 N /usr/games/same-gnome
> 224.49 154.50 N /usr/bin/gnome-window-properties
> 248.44 162.09 N /usr/bin/gnome-default-applications-properties
> 282.62 173.29 N /usr/bin/gnome-at-properties
> 323.72 188.21 N /usr/bin/gnome-typing-monitor
> 363.99 199.93 N /usr/bin/gnome-at-visual
> 394.21 206.95 N /usr/bin/gnome-sound-properties
> 435.14 224.49 N /usr/bin/gnome-at-mobility
> 463.05 234.11 N /usr/bin/gnome-keybinding-properties
> 503.75 248.59 N /usr/bin/gnome-about-me
> 554.00 276.27 N /usr/bin/gnome-display-properties
> 615.48 304.39 N /usr/bin/gnome-network-preferences
> 693.03 342.01 N /usr/bin/gnome-mouse-properties
> 759.90 388.58 N /usr/bin/gnome-appearance-properties
> 937.90 508.47 N /usr/bin/gnome-control-center
> 1109.75 587.57 N /usr/bin/gnome-keyboard-properties
> 1399.05 758.16 N : oocalc
> 1524.64 830.03 N : oodraw
> 1684.31 900.03 N : ooimpress
> 1874.04 993.91 N : oomath
> 2115.12 1081.89 N : ooweb
> 2369.02 1161.99 N : oowriter
Thanks this great effort!
I definitely agree this patch sould be merge to -mm asap.
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 7:51 ` KOSAKI Motohiro
@ 2009-06-08 7:56 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-06-08 7:56 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Andi Kleen, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com,
hugh.dickins@tiscali.co.uk
On Mon, Jun 08, 2009 at 03:51:53PM +0800, KOSAKI Motohiro wrote:
> > On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
> > > One scenario that might be useful to test is what happens when some very large
> > > processes, all mapped and executable exceed memory and fight each other
> > > for the working set. Do you have regressions then compared to without
> > > the patches?
> >
> > I managed to carry out some stress tests for memory tight desktops.
> > The outcome is encouraging: clock time and major faults are reduced
> > by 50%, and pswpin numbers are reduced to ~1/3.
> >
> > Here is the test scenario.
> > - nfsroot gnome desktop with 512M physical memory
> > - run some programs, and switch between the existing windows after
> > starting each new program.
> >
> > The progress timing (seconds) is:
> >
> > before after programs
> > 0.02 0.02 N xeyes
> > 0.75 0.76 N firefox
> > 2.02 1.88 N nautilus
> > 3.36 3.17 N nautilus --browser
> > 5.26 4.89 N gthumb
> > 7.12 6.47 N gedit
> > 9.22 8.16 N xpdf /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf
> > 13.58 12.55 N xterm
> > 15.87 14.57 N mlterm
> > 18.63 17.06 N gnome-terminal
> > 21.16 18.90 N urxvt
> > 26.24 23.48 N gnome-system-monitor
> > 28.72 26.52 N gnome-help
> > 32.15 29.65 N gnome-dictionary
> > 39.66 36.12 N /usr/games/sol
> > 43.16 39.27 N /usr/games/gnometris
> > 48.65 42.56 N /usr/games/gnect
> > 53.31 47.03 N /usr/games/gtali
> > 58.60 52.05 N /usr/games/iagno
> > 65.77 55.42 N /usr/games/gnotravex
> > 70.76 61.47 N /usr/games/mahjongg
> > 76.15 67.11 N /usr/games/gnome-sudoku
> > 86.32 75.15 N /usr/games/glines
> > 92.21 79.70 N /usr/games/glchess
> > 103.79 88.48 N /usr/games/gnomine
> > 113.84 96.51 N /usr/games/gnotski
> > 124.40 102.19 N /usr/games/gnibbles
> > 137.41 114.93 N /usr/games/gnobots2
> > 155.53 125.02 N /usr/games/blackjack
> > 179.85 135.11 N /usr/games/same-gnome
> > 224.49 154.50 N /usr/bin/gnome-window-properties
> > 248.44 162.09 N /usr/bin/gnome-default-applications-properties
> > 282.62 173.29 N /usr/bin/gnome-at-properties
> > 323.72 188.21 N /usr/bin/gnome-typing-monitor
> > 363.99 199.93 N /usr/bin/gnome-at-visual
> > 394.21 206.95 N /usr/bin/gnome-sound-properties
> > 435.14 224.49 N /usr/bin/gnome-at-mobility
> > 463.05 234.11 N /usr/bin/gnome-keybinding-properties
> > 503.75 248.59 N /usr/bin/gnome-about-me
> > 554.00 276.27 N /usr/bin/gnome-display-properties
> > 615.48 304.39 N /usr/bin/gnome-network-preferences
> > 693.03 342.01 N /usr/bin/gnome-mouse-properties
> > 759.90 388.58 N /usr/bin/gnome-appearance-properties
> > 937.90 508.47 N /usr/bin/gnome-control-center
> > 1109.75 587.57 N /usr/bin/gnome-keyboard-properties
> > 1399.05 758.16 N : oocalc
> > 1524.64 830.03 N : oodraw
> > 1684.31 900.03 N : ooimpress
> > 1874.04 993.91 N : oomath
> > 2115.12 1081.89 N : ooweb
> > 2369.02 1161.99 N : oowriter
>
> Thanks this great effort!
> I definitely agree this patch sould be merge to -mm asap.
>
> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Thank you :)
To be complete, here are the free numbers at the end of the tests:
before patch:
total used free shared buffers cached
Mem: 474 467 7 0 0 236
-/+ buffers/cache: 230 243
Swap: 1023 418 605
after patch
total used free shared buffers cached
Mem: 474 457 16 0 0 236
-/+ buffers/cache: 221 253
Swap: 1023 404 619
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 7:39 ` Wu Fengguang
2009-06-08 7:51 ` KOSAKI Motohiro
@ 2009-06-08 17:18 ` Nai Xia
2009-06-09 6:44 ` Wu Fengguang
1 sibling, 1 reply; 69+ messages in thread
From: Nai Xia @ 2009-06-08 17:18 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andi Kleen, KOSAKI Motohiro, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
On Mon, Jun 8, 2009 at 3:39 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
> On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
>> One scenario that might be useful to test is what happens when some very large
>> processes, all mapped and executable exceed memory and fight each other
>> for the working set. Do you have regressions then compared to without
>> the patches?
>
> I managed to carry out some stress tests for memory tight desktops.
> The outcome is encouraging: clock time and major faults are reduced
> by 50%, and pswpin numbers are reduced to ~1/3.
>
> Here is the test scenario.
> - nfsroot gnome desktop with 512M physical memory
> - run some programs, and switch between the existing windows after
> starting each new program.
I think this is a story of VM_EXEC pages fighting against other kind of pages,
but as Andi said, did you test real regression case of VM_EXEC pages fighting
against each other?
"
One scenario that might be useful to test is what happens when some very large
processes, all mapped and executable exceed memory and fight each other
for the working set. Do you have regressions then compared to without
the patches?
-Andi
"
My experices with Compcache(http://code.google.com/p/compcache/) show that
it also has similar improvement in similar case on LTSP
(http://code.google.com/p/compcache/wiki/Performance).
But it does has a non-trivial performance loss even when doing kernel
compilation.
I am not a little surprised when Andrew said it "There must be some cost
somewhere".
So you have found the spots where your patch doing great,
make double sure it will not do something bad in all places,
and that will be perfect. :-)
>
> The progress timing (seconds) is:
>
> before after programs
> 0.02 0.02 N xeyes
> 0.75 0.76 N firefox
> 2.02 1.88 N nautilus
> 3.36 3.17 N nautilus --browser
> 5.26 4.89 N gthumb
> 7.12 6.47 N gedit
> 9.22 8.16 N xpdf /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf
> 13.58 12.55 N xterm
> 15.87 14.57 N mlterm
> 18.63 17.06 N gnome-terminal
> 21.16 18.90 N urxvt
> 26.24 23.48 N gnome-system-monitor
> 28.72 26.52 N gnome-help
> 32.15 29.65 N gnome-dictionary
> 39.66 36.12 N /usr/games/sol
> 43.16 39.27 N /usr/games/gnometris
> 48.65 42.56 N /usr/games/gnect
> 53.31 47.03 N /usr/games/gtali
> 58.60 52.05 N /usr/games/iagno
> 65.77 55.42 N /usr/games/gnotravex
> 70.76 61.47 N /usr/games/mahjongg
> 76.15 67.11 N /usr/games/gnome-sudoku
> 86.32 75.15 N /usr/games/glines
> 92.21 79.70 N /usr/games/glchess
> 103.79 88.48 N /usr/games/gnomine
> 113.84 96.51 N /usr/games/gnotski
> 124.40 102.19 N /usr/games/gnibbles
> 137.41 114.93 N /usr/games/gnobots2
> 155.53 125.02 N /usr/games/blackjack
> 179.85 135.11 N /usr/games/same-gnome
> 224.49 154.50 N /usr/bin/gnome-window-properties
> 248.44 162.09 N /usr/bin/gnome-default-applications-properties
> 282.62 173.29 N /usr/bin/gnome-at-properties
> 323.72 188.21 N /usr/bin/gnome-typing-monitor
> 363.99 199.93 N /usr/bin/gnome-at-visual
> 394.21 206.95 N /usr/bin/gnome-sound-properties
> 435.14 224.49 N /usr/bin/gnome-at-mobility
> 463.05 234.11 N /usr/bin/gnome-keybinding-properties
> 503.75 248.59 N /usr/bin/gnome-about-me
> 554.00 276.27 N /usr/bin/gnome-display-properties
> 615.48 304.39 N /usr/bin/gnome-network-preferences
> 693.03 342.01 N /usr/bin/gnome-mouse-properties
> 759.90 388.58 N /usr/bin/gnome-appearance-properties
> 937.90 508.47 N /usr/bin/gnome-control-center
> 1109.75 587.57 N /usr/bin/gnome-keyboard-properties
> 1399.05 758.16 N : oocalc
> 1524.64 830.03 N : oodraw
> 1684.31 900.03 N : ooimpress
> 1874.04 993.91 N : oomath
> 2115.12 1081.89 N : ooweb
> 2369.02 1161.99 N : oowriter
>
> Note that the oo* commands are actually commented out.
>
> The vmstat numbers are (some relevant ones are marked with *):
>
> before after
> nr_free_pages 1293 3898
> nr_inactive_anon 59956 53460
> nr_active_anon 26815 30026
> nr_inactive_file 2657 3218
> nr_active_file 2019 2806
> nr_unevictable 4 4
> nr_mlock 4 4
> nr_anon_pages 26706 27859
> *nr_mapped 3542 4469
> nr_file_pages 72232 67681
> nr_dirty 1 0
> nr_writeback 123 19
> nr_slab_reclaimable 3375 3534
> nr_slab_unreclaimable 11405 10665
> nr_page_table_pages 8106 7864
> nr_unstable 0 0
> nr_bounce 0 0
> *nr_vmscan_write 394776 230839
> nr_writeback_temp 0 0
> numa_hit 6843353 3318676
> numa_miss 0 0
> numa_foreign 0 0
> numa_interleave 1719 1719
> numa_local 6843353 3318676
> numa_other 0 0
> *pgpgin 5954683 2057175
> *pgpgout 1578276 922744
> *pswpin 1486615 512238
> *pswpout 394568 230685
> pgalloc_dma 277432 56602
> pgalloc_dma32 6769477 3310348
> pgalloc_normal 0 0
> pgalloc_movable 0 0
> pgfree 7048396 3371118
> pgactivate 2036343 1471492
> pgdeactivate 2189691 1612829
> pgfault 3702176 3100702
> *pgmajfault 452116 201343
> pgrefill_dma 12185 7127
> pgrefill_dma32 334384 653703
> pgrefill_normal 0 0
> pgrefill_movable 0 0
> pgsteal_dma 74214 22179
> pgsteal_dma32 3334164 1638029
> pgsteal_normal 0 0
> pgsteal_movable 0 0
> pgscan_kswapd_dma 1081421 1216199
> pgscan_kswapd_dma32 58979118 46002810
> pgscan_kswapd_normal 0 0
> pgscan_kswapd_movable 0 0
> pgscan_direct_dma 2015438 1086109
> pgscan_direct_dma32 55787823 36101597
> pgscan_direct_normal 0 0
> pgscan_direct_movable 0 0
> pginodesteal 3461 7281
> slabs_scanned 564864 527616
> kswapd_steal 2889797 1448082
> kswapd_inodesteal 14827 14835
> pageoutrun 43459 21562
> allocstall 9653 4032
> pgrotated 384216 228631
> htlb_buddy_alloc_success 0 0
> htlb_buddy_alloc_fail 0 0
> unevictable_pgs_culled 0 0
> unevictable_pgs_scanned 0 0
> unevictable_pgs_rescued 0 0
> unevictable_pgs_mlocked 4 4
> unevictable_pgs_munlocked 0 0
> unevictable_pgs_cleared 0 0
> unevictable_pgs_stranded 0 0
> unevictable_pgs_mlockfreed 0 0
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-06-08 17:18 ` Nai Xia
@ 2009-06-09 6:44 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-06-09 6:44 UTC (permalink / raw)
To: Nai Xia
Cc: Andi Kleen, KOSAKI Motohiro, Christoph Lameter, Andrew Morton,
LKML, Elladan, Nick Piggin, Johannes Weiner, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
On Tue, Jun 09, 2009 at 01:18:26AM +0800, Nai Xia wrote:
> On Mon, Jun 8, 2009 at 3:39 PM, Wu Fengguang<fengguang.wu@intel.com> wrote:
> > On Wed, May 20, 2009 at 07:20:24PM +0800, Andi Kleen wrote:
> >> One scenario that might be useful to test is what happens when some very large
> >> processes, all mapped and executable exceed memory and fight each other
> >> for the working set. Do you have regressions then compared to without
> >> the patches?
> >
> > I managed to carry out some stress tests for memory tight desktops.
> > The outcome is encouraging: clock time and major faults are reduced
> > by 50%, and pswpin numbers are reduced to ~1/3.
> >
> > Here is the test scenario.
> > - nfsroot gnome desktop with 512M physical memory
> > - run some programs, and switch between the existing windows after
> > starting each new program.
>
> I think this is a story of VM_EXEC pages fighting against other kind of pages,
> but as Andi said, did you test real regression case of VM_EXEC pages fighting
> against each other?
No. We'd better buy more memory if it's not enough for VM_EXEC pages :-)
Thanks,
Fengguang
> "
> One scenario that might be useful to test is what happens when some very large
> processes, all mapped and executable exceed memory and fight each other
> for the working set. Do you have regressions then compared to without
> the patches?
>
> -Andi
> "
>
> My experices with Compcache(http://code.google.com/p/compcache/) show that
> it also has similar improvement in similar case on LTSP
> (http://code.google.com/p/compcache/wiki/Performance).
> But it does has a non-trivial performance loss even when doing kernel
> compilation.
> I am not a little surprised when Andrew said it "There must be some cost
> somewhere".
>
> So you have found the spots where your patch doing great,
> make double sure it will not do something bad in all places,
> and that will be perfect. :-)
>
> >
> > The progress timing (seconds) is:
> >
> > before after programs
> > 0.02 0.02 N xeyes
> > 0.75 0.76 N firefox
> > 2.02 1.88 N nautilus
> > 3.36 3.17 N nautilus --browser
> > 5.26 4.89 N gthumb
> > 7.12 6.47 N gedit
> > 9.22 8.16 N xpdf /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf
> > 13.58 12.55 N xterm
> > 15.87 14.57 N mlterm
> > 18.63 17.06 N gnome-terminal
> > 21.16 18.90 N urxvt
> > 26.24 23.48 N gnome-system-monitor
> > 28.72 26.52 N gnome-help
> > 32.15 29.65 N gnome-dictionary
> > 39.66 36.12 N /usr/games/sol
> > 43.16 39.27 N /usr/games/gnometris
> > 48.65 42.56 N /usr/games/gnect
> > 53.31 47.03 N /usr/games/gtali
> > 58.60 52.05 N /usr/games/iagno
> > 65.77 55.42 N /usr/games/gnotravex
> > 70.76 61.47 N /usr/games/mahjongg
> > 76.15 67.11 N /usr/games/gnome-sudoku
> > 86.32 75.15 N /usr/games/glines
> > 92.21 79.70 N /usr/games/glchess
> > 103.79 88.48 N /usr/games/gnomine
> > 113.84 96.51 N /usr/games/gnotski
> > 124.40 102.19 N /usr/games/gnibbles
> > 137.41 114.93 N /usr/games/gnobots2
> > 155.53 125.02 N /usr/games/blackjack
> > 179.85 135.11 N /usr/games/same-gnome
> > 224.49 154.50 N /usr/bin/gnome-window-properties
> > 248.44 162.09 N /usr/bin/gnome-default-applications-properties
> > 282.62 173.29 N /usr/bin/gnome-at-properties
> > 323.72 188.21 N /usr/bin/gnome-typing-monitor
> > 363.99 199.93 N /usr/bin/gnome-at-visual
> > 394.21 206.95 N /usr/bin/gnome-sound-properties
> > 435.14 224.49 N /usr/bin/gnome-at-mobility
> > 463.05 234.11 N /usr/bin/gnome-keybinding-properties
> > 503.75 248.59 N /usr/bin/gnome-about-me
> > 554.00 276.27 N /usr/bin/gnome-display-properties
> > 615.48 304.39 N /usr/bin/gnome-network-preferences
> > 693.03 342.01 N /usr/bin/gnome-mouse-properties
> > 759.90 388.58 N /usr/bin/gnome-appearance-properties
> > 937.90 508.47 N /usr/bin/gnome-control-center
> > 1109.75 587.57 N /usr/bin/gnome-keyboard-properties
> > 1399.05 758.16 N : oocalc
> > 1524.64 830.03 N : oodraw
> > 1684.31 900.03 N : ooimpress
> > 1874.04 993.91 N : oomath
> > 2115.12 1081.89 N : ooweb
> > 2369.02 1161.99 N : oowriter
> >
> > Note that the oo* commands are actually commented out.
> >
> > The vmstat numbers are (some relevant ones are marked with *):
> >
> > before after
> > nr_free_pages 1293 3898
> > nr_inactive_anon 59956 53460
> > nr_active_anon 26815 30026
> > nr_inactive_file 2657 3218
> > nr_active_file 2019 2806
> > nr_unevictable 4 4
> > nr_mlock 4 4
> > nr_anon_pages 26706 27859
> > *nr_mapped 3542 4469
> > nr_file_pages 72232 67681
> > nr_dirty 1 0
> > nr_writeback 123 19
> > nr_slab_reclaimable 3375 3534
> > nr_slab_unreclaimable 11405 10665
> > nr_page_table_pages 8106 7864
> > nr_unstable 0 0
> > nr_bounce 0 0
> > *nr_vmscan_write 394776 230839
> > nr_writeback_temp 0 0
> > numa_hit 6843353 3318676
> > numa_miss 0 0
> > numa_foreign 0 0
> > numa_interleave 1719 1719
> > numa_local 6843353 3318676
> > numa_other 0 0
> > *pgpgin 5954683 2057175
> > *pgpgout 1578276 922744
> > *pswpin 1486615 512238
> > *pswpout 394568 230685
> > pgalloc_dma 277432 56602
> > pgalloc_dma32 6769477 3310348
> > pgalloc_normal 0 0
> > pgalloc_movable 0 0
> > pgfree 7048396 3371118
> > pgactivate 2036343 1471492
> > pgdeactivate 2189691 1612829
> > pgfault 3702176 3100702
> > *pgmajfault 452116 201343
> > pgrefill_dma 12185 7127
> > pgrefill_dma32 334384 653703
> > pgrefill_normal 0 0
> > pgrefill_movable 0 0
> > pgsteal_dma 74214 22179
> > pgsteal_dma32 3334164 1638029
> > pgsteal_normal 0 0
> > pgsteal_movable 0 0
> > pgscan_kswapd_dma 1081421 1216199
> > pgscan_kswapd_dma32 58979118 46002810
> > pgscan_kswapd_normal 0 0
> > pgscan_kswapd_movable 0 0
> > pgscan_direct_dma 2015438 1086109
> > pgscan_direct_dma32 55787823 36101597
> > pgscan_direct_normal 0 0
> > pgscan_direct_movable 0 0
> > pginodesteal 3461 7281
> > slabs_scanned 564864 527616
> > kswapd_steal 2889797 1448082
> > kswapd_inodesteal 14827 14835
> > pageoutrun 43459 21562
> > allocstall 9653 4032
> > pgrotated 384216 228631
> > htlb_buddy_alloc_success 0 0
> > htlb_buddy_alloc_fail 0 0
> > unevictable_pgs_culled 0 0
> > unevictable_pgs_scanned 0 0
> > unevictable_pgs_rescued 0 0
> > unevictable_pgs_mlocked 4 4
> > unevictable_pgs_munlocked 0 0
> > unevictable_pgs_cleared 0 0
> > unevictable_pgs_stranded 0 0
> > unevictable_pgs_mlockfreed 0 0
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> >
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 4:41 ` KOSAKI Motohiro
` (2 preceding siblings ...)
2009-05-19 6:25 ` Wu Fengguang
@ 2009-05-19 7:15 ` Wu Fengguang
2009-05-19 7:20 ` KOSAKI Motohiro
3 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 7:15 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> Hi
>
> Thanks for great works.
>
>
> > SUMMARY
> > =======
> > The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
> >
> >
> > SCENARIO
> > ========
> > The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> > where 10% of the pages will be activated:
> >
> > for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> > iotrace.rb --load pattern-hot-10 --play /b/sparse
>
>
> Which can I download iotrace.rb?
>
>
> > and monitor /proc/vmstat during the time. The test box has 2G memory.
> >
> >
> > ANALYZES
> > ========
> >
> > I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> > patch, and fetched the vmstat numbers on
> >
> > (1) begin: shortly after the big read IO starts;
> > (2) end: just before the big read IO stops;
> > (3) restore: the big read IO stops and the zsh working set restored
> >
> > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> > begin: 2481 2237 8694 630 0 574299
> > end: 275 231976 233914 633 776271 20933042
> > restore: 370 232154 234524 691 777183 20958453
> >
> > begin: 2434 2237 8493 629 0 574195
> > end: 284 231970 233536 632 771918 20896129
> > restore: 399 232218 234789 690 774526 20957909
> >
> > and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
>
> I don't think it is proper comparision.
> you need either following comparision. otherwise we insert many guess into the analysis.
>
> - 2.6.29 with and without VM_EXEC patch
> - 2.6.30-rc4-mm with and without VM_EXEC patch
>
>
> >
> > begin: 2479 2344 9659 210 0 579643
> > end: 284 232010 234142 260 772776 20917184
> > restore: 379 232159 234371 301 774888 20967849
> >
> > The numbers show that
> >
> > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > I'd attribute that improvement to the mmap readahead improvements :-)
> >
> > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > That's a huge improvement - which means with the VM_EXEC protection logic,
> > active mmap pages is pretty safe even under partially cache hot streaming IO.
> >
> > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > That roughly means the active mmap pages get 20.8 more chances to get
> > re-referenced to stay in memory.
> >
> > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > dropped pages are mostly inactive ones. The patch has almost no impact in
> > this aspect, that means it won't unnecessarily increase memory pressure.
> > (In contrast, your 20% mmap protection ratio will keep them all, and
> > therefore eliminate the extra 41 major faults to restore working set
> > of zsh etc.)
More results on X desktop, kernel 2.6.30-rc4-mm:
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
VM_EXEC protection ON:
begin: 9740 8920 64075 561 0 678360
end: 768 218254 220029 565 798953 21057006
restore: 857 218543 220987 606 799462 21075710
restore X: 2414 218560 225344 797 799462 21080795
VM_EXEC protection OFF:
begin: 9368 5035 26389 554 0 633391
end: 770 218449 221230 661 646472 17832500
restore: 1113 218466 220978 710 649881 17905235
restore X: 2687 218650 225484 947 802700 21083584
The added "restore X" means after IO, switch back and forth between the urxvt
and firefox windows to restore their working set. I cannot explain why the
absolute nr_mapped grows larger at the end of VM_EXEC OFF case. Maybe it's
because urxvt is the foreground window during the first run, and firefox is the
foreground window during the second run?
Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
the original size - during the streaming IO.
The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
process.
RAW DATA
--------
status before tests:
wfg@hp ~% ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.8 0.0 10316 792 ? Ss 14:38 0:02 init [2]
root 2 0.0 0.0 0 0 ? S< 14:38 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S< 14:38 0:00 [migration/0]
root 4 0.0 0.0 0 0 ? S< 14:38 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< 14:38 0:00 [watchdog/0]
root 6 0.0 0.0 0 0 ? S< 14:38 0:00 [migration/1]
root 7 0.0 0.0 0 0 ? S< 14:38 0:00 [ksoftirqd/1]
root 8 0.0 0.0 0 0 ? S< 14:38 0:00 [watchdog/1]
root 9 0.0 0.0 0 0 ? S< 14:38 0:00 [events/0]
root 10 0.0 0.0 0 0 ? S< 14:38 0:00 [events/1]
root 11 0.0 0.0 0 0 ? S< 14:38 0:00 [khelper]
root 16 0.0 0.0 0 0 ? S< 14:38 0:00 [async/mgr]
root 160 0.0 0.0 0 0 ? S< 14:38 0:00 [kintegrityd/0]
root 161 0.0 0.0 0 0 ? S< 14:38 0:00 [kintegrityd/1]
root 163 0.0 0.0 0 0 ? S< 14:38 0:00 [kblockd/0]
root 164 0.0 0.0 0 0 ? S< 14:38 0:00 [kblockd/1]
root 165 0.0 0.0 0 0 ? S< 14:38 0:00 [kacpid]
root 166 0.0 0.0 0 0 ? S< 14:38 0:00 [kacpi_notify]
root 274 0.0 0.0 0 0 ? S< 14:38 0:00 [ata/0]
root 275 0.0 0.0 0 0 ? S< 14:38 0:00 [ata/1]
root 276 0.0 0.0 0 0 ? S< 14:38 0:00 [ata_aux]
root 280 0.0 0.0 0 0 ? S< 14:38 0:00 [ksuspend_usbd]
root 284 0.0 0.0 0 0 ? S< 14:38 0:00 [khubd]
root 287 0.0 0.0 0 0 ? S< 14:38 0:00 [kseriod]
root 329 0.0 0.0 0 0 ? S< 14:38 0:00 [kondemand/0]
root 330 0.0 0.0 0 0 ? S< 14:38 0:00 [kondemand/1]
root 365 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-0]
root 367 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-1]
root 369 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-2]
root 371 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-3]
root 373 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-4]
root 375 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-5]
root 377 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-6]
root 379 0.0 0.0 0 0 ? S< 14:38 0:00 [rt-test-7]
root 382 0.0 0.0 0 0 ? S 14:38 0:00 [khungtaskd]
root 383 0.0 0.0 0 0 ? S 14:38 0:00 [pdflush]
root 384 0.0 0.0 0 0 ? S 14:38 0:00 [pdflush]
root 385 0.0 0.0 0 0 ? S< 14:38 0:00 [kswapd0]
root 386 0.0 0.0 0 0 ? S< 14:38 0:00 [aio/0]
root 387 0.0 0.0 0 0 ? S< 14:38 0:00 [aio/1]
root 388 0.0 0.0 0 0 ? S< 14:38 0:00 [nfsiod]
root 390 0.0 0.0 0 0 ? S< 14:38 0:00 [crypto/0]
root 391 0.0 0.0 0 0 ? S< 14:38 0:00 [crypto/1]
root 1118 0.0 0.0 0 0 ? S< 14:38 0:00 [iscsi_eh]
root 1122 0.0 0.0 0 0 ? S< 14:38 0:00 [scsi_eh_0]
root 1125 0.0 0.0 0 0 ? S< 14:38 0:00 [scsi_eh_1]
root 1128 0.0 0.0 0 0 ? S< 14:38 0:00 [scsi_eh_2]
root 1136 0.0 0.0 0 0 ? S< 14:38 0:00 [scsi_eh_3]
root 1139 0.0 0.0 0 0 ? S< 14:38 0:00 [scsi_eh_4]
root 1276 0.0 0.0 0 0 ? S< 14:38 0:00 [kpsmoused]
root 1301 0.0 0.0 0 0 ? S< 14:38 0:00 [usbhid_resumer]
root 1312 0.0 0.0 0 0 ? S< 14:38 0:00 [rpciod/0]
root 1313 0.0 0.0 0 0 ? S< 14:38 0:00 [rpciod/1]
root 1488 0.0 0.0 0 0 ? S< 14:38 0:00 [iwlagn]
root 1490 0.0 0.0 0 0 ? S< 14:38 0:00 [phy0]
root 1524 0.0 0.0 0 0 ? S< 14:38 0:00 [hd-audio0]
root 1577 0.0 0.0 0 0 ? S< 14:38 0:00 [kjournald2]
root 1578 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-worker-0]
root 1579 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-submit-0]
root 1580 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-delalloc-]
root 1581 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-fixup-0]
root 1582 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-0]
root 1583 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-2]
root 1584 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-4]
root 1585 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-6]
root 1586 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1587 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1588 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1589 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1590 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1591 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1592 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1593 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-met]
root 1594 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-wri]
root 1595 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-wri]
root 1596 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-wri]
root 1597 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-endio-wri]
root 1598 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-cleaner]
root 1599 0.0 0.0 0 0 ? S< 14:38 0:00 [btrfs-transacti]
daemon 1658 0.0 0.0 8024 528 ? Ss 14:38 0:00 /sbin/portmap
root 1670 0.0 0.0 10136 792 ? Ss 14:38 0:00 /sbin/rpc.statd
root 1679 0.0 0.0 26952 660 ? Ss 14:38 0:00 /usr/sbin/rpc.idmapd
root 1789 0.0 0.0 3800 648 ? Ss 14:39 0:00 /usr/sbin/acpid
104 1799 0.0 0.0 21084 996 ? Ss 14:40 0:00 /usr/bin/dbus-daemon --system
root 1811 0.0 0.0 48872 1208 ? Ss 14:40 0:00 /usr/sbin/sshd
root 1844 0.0 0.0 0 0 ? S< 14:40 0:00 [lockd]
root 1845 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1846 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1847 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1848 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1849 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1850 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1851 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1852 0.0 0.0 0 0 ? S< 14:40 0:00 [nfsd]
root 1856 0.0 0.0 14464 420 ? Ss 14:40 0:00 /usr/sbin/rpc.mountd --manage-gids
106 1867 0.2 0.2 29280 4164 ? Ss 14:40 0:00 /usr/sbin/hald
root 1868 0.0 0.0 17812 1172 ? S 14:40 0:00 hald-runner
root 1891 0.0 0.0 19936 1132 ? S 14:40 0:00 /usr/lib/hal/hald-addon-cpufreq
106 1892 0.0 0.0 16608 988 ? S 14:40 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
pulse 1902 0.0 0.1 102024 2664 ? S<s 14:40 0:00 /usr/bin/pulseaudio --system --daemonize --high-priority --log-targe
pulse 1903 0.0 0.1 56024 2768 ? S 14:40 0:00 /usr/lib/pulseaudio/pulse/gconf-helper
pulse 1905 0.0 0.1 37356 2700 ? S 14:40 0:00 /usr/lib/libgconf2-4/gconfd-2 4
root 1932 0.0 0.0 45636 1268 tty1 Ss 14:40 0:00 /bin/login --
root 1933 0.0 0.0 3800 584 tty2 Ss+ 14:40 0:00 /sbin/getty 38400 tty2
root 1934 0.0 0.0 3800 584 tty3 Ss+ 14:40 0:00 /sbin/getty 38400 tty3
root 1935 0.0 0.0 3800 588 tty4 Ss+ 14:40 0:00 /sbin/getty 38400 tty4
root 1936 0.0 0.0 3800 588 tty5 Ss+ 14:40 0:00 /sbin/getty 38400 tty5
root 1937 0.0 0.0 3800 584 tty6 Ss+ 14:40 0:00 /sbin/getty 38400 tty6
root 1938 0.0 0.0 3800 592 ttyS0 Ss+ 14:40 0:00 /sbin/getty -L ttyS0 115200 vt102
wfg 1939 0.1 0.1 40028 3156 tty1 S 14:40 0:00 -zsh
wfg 1955 0.0 0.0 9388 1496 tty1 S+ 14:40 0:00 /bin/bash /usr/bin/startx
wfg 1972 0.0 0.0 15444 920 tty1 S+ 14:40 0:00 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /t
root 1973 2.4 0.8 97148 16272 tty7 Ss+ 14:40 0:05 /usr/bin/X11/X -nolisten tcp
wfg 2016 0.7 0.2 104840 5812 tty1 S 14:41 0:01 /usr/bin/fluxbox
wfg 2047 0.0 0.0 35868 676 ? Ss 14:41 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /home/wf
wfg 2050 0.0 0.0 23868 736 tty1 S 14:41 0:00 /usr/bin/dbus-launch --exit-with-session /home/wfg/.xsession
wfg 2051 0.0 0.0 21084 532 ? Ss 14:41 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --sessio
wfg 2061 0.0 0.0 31548 940 ? Ss 14:41 0:00 /usr/lib/scim-1.0/scim-helper-manager
wfg 2062 0.1 0.2 144616 5772 ? Ssl 14:41 0:00 /usr/lib/scim-1.0/scim-panel-gtk --display :0.0 -c simple -d --no-st
wfg 2064 0.1 0.5 55928 9932 ? Ss 14:41 0:00 /usr/lib/scim-1.0/scim-launcher -d -c simple -e pinyin -f x11
wfg 2065 0.2 0.4 139192 9352 tty1 S 14:41 0:00 urxvt
wfg 2068 0.9 0.1 46664 3876 pts/0 Ss+ 14:41 0:01 zsh
wfg 2084 3.3 2.5 438088 49824 pts/0 SNl 14:42 0:03 /usr/lib/iceweasel/firefox-bin -a iceweasel
wfg 2086 0.1 0.1 41580 2800 pts/0 SN 14:42 0:00 /usr/lib/libgconf2-4/gconfd-2 11
root 2118 1.0 0.1 63868 2956 ? Ss 14:44 0:00 sshd: wfg [priv]
wfg 2120 0.6 0.0 63996 1744 ? S 14:44 0:00 sshd: wfg@pts/1
wfg 2121 4.3 0.1 44284 3260 pts/1 Ss 14:44 0:00 -zsh
root 2142 0.8 0.1 63868 2956 ? Ss 14:44 0:00 sshd: wfg [priv]
wfg 2144 0.2 0.0 63996 1768 ? S 14:44 0:00 sshd: wfg@pts/2
wfg 2145 5.1 0.1 44284 3272 pts/2 Ss+ 14:44 0:00 -zsh
wfg 2170 0.0 0.0 18984 1116 pts/1 R+ 14:44 0:00 ps aux
wfg@hp ~% cat /proc/meminfo
MemTotal: 1979588 kB
MemFree: 1663652 kB
Buffers: 152 kB
Cached: 132152 kB
SwapCached: 0 kB
Active: 95964 kB
Inactive: 106692 kB
Active(anon): 75760 kB
Inactive(anon): 0 kB
Active(file): 20204 kB
Inactive(file): 106692 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 70444 kB
Mapped: 38184 kB
Slab: 49192 kB
SReclaimable: 37324 kB
SUnreclaim: 11868 kB
PageTables: 4920 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 989792 kB
Committed_AS: 166344 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 355912 kB
VmallocChunk: 34359354931 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 93888 kB
DirectMap2M: 1961984 kB
VM_EXEC protection ON:
% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9737 5147 29955 561 0 637722
9740 8920 64075 561 0 678360
9740 12791 98061 561 0 718865
9740 16539 132232 561 0 759370
9740 20372 166287 561 0 801824
9740 24205 201365 561 0 842329
9740 28064 235953 561 0 884676
9740 31854 269988 561 0 927029
9740 35746 305535 561 0 967535
9740 39536 339478 561 0 1009880
9740 43417 373641 561 0 1050389
9740 54729 381210 561 6912 1109898
9740 58435 377330 561 7328 1183666
9740 61997 374070 561 7328 1257928
9740 65040 370950 561 7328 1332616
9740 68491 368348 561 7328 1406342
9740 71889 364481 561 7328 1481793
9740 74833 361684 561 7328 1556333
9740 77826 358745 561 7328 1632841
9740 81287 356122 561 7328 1707073
9740 84845 352501 561 7328 1781928
9740 88442 349293 561 7328 1856702
9740 92007 345926 561 7328 1931420
9740 95537 343428 561 7328 2004754
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9740 99076 339752 561 7328 2079395
9740 102617 336155 561 7328 2153574
9740 106227 332575 561 7328 2228162
9740 109757 329434 561 7328 2302880
9740 113322 326653 561 7328 2377673
9740 116920 322555 561 7328 2452726
9740 120541 318326 561 7328 2527851
9740 124101 315354 561 7328 2602099
9740 127692 311539 561 7328 2676899
9740 131259 307116 561 7328 2751590
9740 134799 304935 561 7328 2824614
9740 138298 301002 561 7328 2898581
9740 141890 297370 561 7328 2973273
9740 145455 294740 561 7328 3046973
9740 149056 290937 561 7328 3121656
9740 152595 287499 561 7328 3196095
9740 156165 284079 561 7328 3270639
9740 159706 279972 561 7328 3344822
9740 163184 276041 561 7328 3419006
9740 166767 272461 561 7328 3492500
9740 170337 268830 561 7328 3566045
9740 173919 265143 561 7328 3640676
9740 177478 261685 561 7328 3715228
9740 181040 258126 561 7328 3789731
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9740 184631 254802 561 7328 3863980
9740 188182 251125 561 7328 3938712
9740 191773 246756 561 7328 4013327
9740 195241 244868 561 7328 4085672
9740 198805 240257 561 7328 4160538
9740 202313 237616 561 7328 4234145
9740 205883 232906 561 7328 4308496
9740 209435 229485 561 7328 4381419
9740 212977 226463 561 7328 4455412
9740 216454 223230 561 7328 4528635
9740 218700 220407 561 8614 4600912
9740 218565 220153 561 12267 4674967
9740 218435 221182 561 15894 4748415
9740 218547 220048 561 19348 4822991
9740 218386 220145 561 23027 4895718
9740 218327 220460 561 26635 4969965
9616 218528 220848 561 29983 5042835
9620 218381 220500 561 33648 5117058
9620 218263 220336 561 37284 5191698
9620 218112 220231 561 40994 5264628
9620 218335 219960 561 44344 5338229
9620 218243 220260 561 47916 5411545
9620 218081 220230 561 51565 5484453
9620 218384 219952 561 54837 5557957
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9620 218233 220589 561 58538 5632008
9620 218481 220082 561 61815 5705965
9620 218361 220972 561 65463 5779613
9620 218310 220031 561 69063 5854200
7849 218353 219904 561 72552 5926925
5073 218245 220358 562 76221 6001144
2496 218189 220285 562 79836 6075799
2496 218054 219980 562 83551 6150499
2496 218309 219909 562 86861 6224055
2496 218246 220356 562 90494 6298165
2496 218076 220046 562 94141 6372175
2496 218328 220853 562 97448 6445627
2498 218320 220278 564 100995 6520225
2498 218357 219945 564 104559 6594735
2498 218253 219914 564 108171 6668947
2498 218203 220376 564 111807 6741552
2498 218189 220294 564 115370 6816163
2498 218125 219765 564 119014 6890796
2498 218313 219947 564 122394 6964372
2498 218310 219950 564 125987 7038875
2498 218089 221069 564 129695 7112421
2498 218340 219942 564 133041 7187200
2498 218350 220677 564 136611 7260586
2498 218408 220854 564 140067 7334883
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2498 218398 219873 564 143626 7409357
2498 218344 220269 564 147260 7483508
2498 218134 220223 564 150988 7558268
2498 218060 220169 564 154621 7632472
2498 218306 220355 564 157941 7706417
2498 218273 219987 564 161554 7780305
2498 218172 220024 564 165204 7853585
2498 218325 219904 564 168617 7928056
2498 218300 220323 564 172232 8002176
2498 218203 220346 564 175878 8076745
2498 218092 220233 564 179569 8151473
2498 218306 219890 564 182921 8225080
2498 218323 219937 564 186494 8299522
2498 218162 220258 564 190204 8373861
2498 218378 220492 564 193523 8447890
2498 218398 220024 564 197083 8521832
2498 218375 220909 564 200610 8595504
2498 218341 219888 564 204193 8670039
2498 218257 220324 564 207805 8742357
2498 218138 220251 564 211473 8817052
2498 218295 219871 564 214906 8890706
2498 218397 220311 564 218360 8964713
2498 218217 220140 564 222037 9038549
2498 218051 220235 564 225683 9112128
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
2498 218328 219932 564 228979 9186631
2498 218189 219975 564 232677 9259389
2498 218298 219931 564 236155 9333829
2498 218243 219890 564 239769 9408429
2498 218230 220351 564 243331 9482485
1130 218151 219747 564 246990 9556988
775 218318 221286 564 250327 9629446
775 218241 220802 564 253963 9704045
775 218109 220216 564 257582 9778461
775 218333 220019 564 260955 9852288
775 218310 219886 564 264527 9924983
775 218168 221020 564 268200 9998462
775 218374 220018 564 271551 10072805
775 218317 220907 564 275105 10146423
775 218299 219934 564 278658 10220928
775 218300 219965 564 282206 10293576
775 218286 219979 564 285810 10368090
775 218161 219956 564 289484 10442377
774 218421 220899 564 292728 10515045
774 218242 220528 564 296456 10589300
774 218128 220297 564 300067 10663953
774 218000 220233 564 303775 10736841
774 218351 219945 564 306990 10810260
774 218295 219978 564 310635 10884800
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
774 218420 220558 564 314014 10958616
774 218407 220101 564 317617 11032589
774 218320 221071 564 321222 11106217
774 218388 220165 564 324689 11180786
774 218365 219941 564 328230 11253418
774 218206 220324 564 331948 11327698
774 218228 219847 564 335506 11401879
770 218454 220139 564 338846 11475601
770 218252 220989 564 342535 11549227
770 218102 220268 564 346182 11623826
770 218340 220368 564 349510 11697371
770 218345 219960 564 353085 11770033
770 218191 220530 564 356788 11844095
770 218448 220019 564 360066 11917812
768 218277 220277 564 363703 11991470
768 218334 219919 564 367181 12064481
768 218377 220185 564 370718 12138384
768 218231 219849 564 374413 12212439
768 218426 220284 564 377691 12285601
768 218320 219986 564 381325 12358448
768 218212 220414 564 384982 12432479
768 218104 220266 564 388670 12507241
768 218325 219916 564 392015 12580849
768 218345 220024 564 395585 12655192
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
768 218154 220274 564 399263 12728833
768 218385 220943 564 402536 12802248
768 218333 219940 564 406137 12875088
768 218310 219950 564 409712 12949461
768 218397 220271 564 413198 13023563
768 218288 219876 564 416856 13098002
768 218389 220474 564 420228 13170929
768 218348 219958 564 423787 13243559
768 218242 219858 564 427452 13317693
768 218484 220791 564 430745 13390565
768 218357 220333 564 434390 13464639
768 218156 220278 564 438078 13537783
768 218118 220220 564 441706 13612159
768 218367 219970 564 445023 13685638
768 218347 220229 565 448623 13759886
769 218165 220923 565 452323 13833912
769 218489 220057 565 455565 13907931
769 218309 220970 565 459273 13981707
769 218410 219921 565 462707 14056149
769 218308 219949 565 466327 14128875
769 218289 220353 565 469927 14202994
769 218235 219857 565 473540 14277225
769 218390 220001 565 476858 14350371
769 218229 220381 565 480506 14423884
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
769 218136 220250 565 484179 14497379
769 218333 219935 565 487535 14570954
769 218249 220915 565 491129 14644242
769 218122 220136 565 494805 14718972
769 218369 220975 565 498093 14792388
769 218346 220065 565 501696 14866987
769 218330 219960 565 505247 14939588
769 218312 219982 565 508818 15014087
769 218299 220315 565 512421 15088240
769 218297 219934 565 515972 15162148
769 218316 221198 565 519426 15235217
769 218336 220682 565 522986 15309720
769 218125 220201 565 526694 15383119
769 218052 220210 565 530347 15457278
769 218340 219953 565 533625 15530728
769 218267 220058 565 537257 15605205
769 218390 220352 565 540721 15679276
769 218346 219977 565 544293 15753302
769 218318 221029 565 547839 15826714
769 218385 220258 565 551316 15901240
769 218249 220054 565 554970 15973871
769 218234 220357 565 558544 16048093
769 218137 220326 565 562221 16122725
769 218342 219928 565 565582 16196396
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
769 218255 221137 565 569156 16269720
769 218127 220208 565 572843 16344319
769 218324 220286 565 576150 16417895
769 218292 220042 565 579762 16490463
769 218359 219944 565 583261 16565000
769 218283 220500 565 586855 16639023
769 218330 219940 565 590398 16713063
769 218463 220831 565 593800 16786496
769 218368 219903 565 597382 16861000
769 218267 220324 565 601032 16933344
769 218118 220281 565 604740 17008040
769 218020 219878 565 608418 17082703
769 218364 220546 565 611609 17155480
769 218229 220202 565 615262 17229471
769 218359 220594 565 618636 17303079
769 218347 219955 565 622207 17375756
769 218271 220063 565 625832 17450228
769 218334 220449 565 629335 17524283
769 218429 220515 565 632789 17597558
769 218426 220608 565 636282 17671695
769 218313 219958 565 639906 17744423
769 218255 219852 565 643513 17818191
769 218389 220132 565 646839 17891351
769 218325 219979 565 650443 17964015
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
769 218210 219793 565 654108 18038167
769 218373 220424 565 657427 18111070
769 218207 220385 565 661102 18183350
769 218173 220386 565 664685 18257885
769 218473 220072 565 667960 18331346
769 218251 221022 565 671670 18404849
769 218206 220193 565 675264 18479513
769 218057 220182 565 678931 18552337
769 218339 219996 565 682225 18625722
769 218210 220092 565 685903 18700257
769 218405 220569 565 689232 18774089
769 218421 220905 565 692786 18847221
769 218380 219950 565 696317 18921725
769 218309 219908 565 699920 18994483
769 218273 220013 565 703505 19068446
769 218433 220911 565 706825 19141317
768 218301 219970 565 710468 19215533
768 218258 220365 565 714091 19288197
768 218098 220333 565 717810 19362893
768 218463 220159 565 721011 19436162
768 218284 221113 565 724677 19509709
768 218094 220241 565 728354 19582627
768 218343 219927 565 731671 19656171
768 218344 219926 565 735260 19730678
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
768 218110 221120 565 739012 19804222
768 218454 220426 565 742234 19877989
768 218337 220677 565 745838 19952146
768 218335 219926 565 749365 20024804
768 218286 220117 565 752977 20099148
768 218382 220150 565 756440 20172469
768 218377 220548 565 759918 20246301
768 218258 220369 565 763555 20318579
768 218221 220310 565 767151 20393181
768 218105 219711 565 770847 20467744
768 218365 220869 565 774122 20540442
768 218259 220304 565 777746 20614615
768 218069 220270 565 781433 20687502
768 218347 219927 565 784721 20761046
768 218305 219914 565 788352 20835605
768 218143 221068 565 792032 20909100
768 218460 220845 565 795281 20982533
768 218254 220029 565 798953 21057006
857 218543 220987 606 799462 21075710
857 218543 220987 606 799462 21075713
857 218543 220987 606 799462 21075934
857 218543 220987 606 799462 21075937
857 218543 220987 606 799462 21075939
857 218543 220987 606 799462 21076151
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
857 218543 220987 606 799462 21076153
857 218543 220987 606 799462 21076156
857 218543 220987 606 799462 21076272
857 218543 220987 606 799462 21076275
857 218543 220987 606 799462 21076277
1221 218543 223637 671 799462 21076494
2379 218544 225770 795 799462 21079005
2411 218544 225360 797 799462 21079616
2411 218544 225360 797 799462 21079884
2411 218544 225360 797 799462 21079887
2411 218544 225360 797 799462 21079889
2411 218544 225360 797 799462 21080174
2411 218544 225360 797 799462 21080176
2411 218560 225344 797 799462 21080245
2411 218560 225344 797 799462 21080459
2411 218560 225344 797 799462 21080618
2414 218560 225344 797 799462 21080620
2414 218560 225344 797 799462 21080747
2414 218560 225344 797 799462 21080749
2414 218560 225344 797 799462 21080752
2414 218560 225344 797 799462 21080779
2414 218560 225344 797 799462 21080782
2414 218560 225344 797 799462 21080784
2414 218560 225344 797 799462 21080795
VM_EXEC protection OFF:
~% vmmon nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9368 5035 26389 554 0 633391
9368 5035 26389 554 0 633397
9559 5036 26836 561 0 633888
9559 5036 26924 561 0 633891
9562 7682 52723 561 0 660980
9566 11451 85796 561 0 703380
9566 15272 120910 561 0 743891
9626 19105 154964 561 0 784401
9627 22855 188885 561 0 826784
9627 26726 223137 561 0 867294
9627 30517 257231 561 0 909640
9658 34389 292240 561 0 950160
9658 38198 326910 561 0 992506
9658 42038 361419 561 0 1033010
9658 45802 391241 561 3136 1078165
9658 56707 380157 561 7200 1145085
9658 60225 376640 561 7200 1219657
9658 63603 373594 561 7200 1293906
9658 66626 370429 561 7232 1368607
9658 70123 366132 561 7232 1443441
9658 73720 363346 561 7232 1517044
9658 77217 360004 561 7232 1593619
9658 80502 356975 561 7232 1665902
9658 84019 353154 561 7232 1740955
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9658 87480 349734 561 7232 1815507
9658 91067 346656 561 7232 1891608
9658 94589 343203 561 7232 1964477
9658 98179 339367 561 7232 2039321
9658 101725 335960 561 7232 2113511
9658 105278 332913 561 7232 2187360
9658 108681 329423 561 7232 2262025
9658 112251 325864 561 7232 2338186
9658 115621 323150 561 7232 2412595
9658 119144 320330 561 7232 2487342
9658 122626 315657 561 7232 2560440
9658 126277 313211 561 7232 2635624
9658 129796 309471 561 7232 2710325
9658 133386 305410 561 7232 2784874
9658 136913 301492 561 7232 2859128
9658 140470 298382 561 7232 2933644
9658 144123 294611 561 7232 3008344
9658 147701 291873 561 7232 3082991
9658 151312 287947 561 7232 3158135
9658 154913 284134 561 7232 3232826
9658 158451 280777 561 7232 3307472
9658 162055 276654 561 7232 3381431
9658 165555 274108 561 7232 3455039
9658 169125 270786 561 7232 3529200
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
9658 172695 266946 561 7232 3604088
9658 176296 263486 561 7232 3678732
9658 179866 259475 561 7232 3753866
9658 183436 255670 561 7232 3828625
9658 187037 251425 561 7232 3903257
9658 190587 249279 561 7232 3976094
9658 194086 245178 561 7232 4050424
9658 197689 241212 561 7232 4125056
9658 201271 237632 561 7232 4199737
9658 204841 233834 561 7232 4274720
9658 208431 230131 561 7232 4349220
9658 212011 227400 561 7232 4422819
9658 215489 223735 561 7232 4497071
9658 218385 220541 561 7867 4571286
9658 218322 220444 561 11479 4644623
9658 218216 220390 561 15175 4720412
9658 218493 220943 561 18547 4794378
9658 218358 220087 561 22179 4867094
9658 218209 220140 561 25877 4941694
9658 218351 219984 561 29296 5015486
7781 218355 220984 561 32985 5088777
7765 218410 220692 561 36465 5163337
7765 218335 219950 561 40058 5237934
7765 218322 220475 561 43651 5310193
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
7766 218179 219812 562 47343 5384969
7766 218433 220367 562 50572 5457723
7766 218249 220490 562 54243 5530170
7766 218150 220397 562 57922 5604916
7766 218462 220052 562 61176 5679897
7766 218399 220019 562 64819 5753551
7766 218324 220222 572 68454 5827860
7811 218436 220907 590 71846 5901072
6117 218400 220469 592 75586 5975733
3100 218390 220672 592 79362 6050300
930 218403 220296 592 83163 6124830
921 218372 219981 593 86784 6199369
925 218291 220301 593 90429 6273641
925 218102 220339 593 94177 6346459
925 218392 220984 593 97399 6418998
925 218284 220728 593 101066 6493286
925 218210 220392 593 104720 6568020
925 218493 220917 593 108034 6641495
925 218373 221009 593 111669 6716048
925 218425 220525 593 115157 6790465
925 218361 219997 593 118760 6863999
925 218329 220445 593 122363 6937327
925 218234 220411 593 126007 7011965
925 218156 220297 593 129675 7086660
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
925 218401 219989 593 133003 7160612
925 218374 220046 593 136607 7234710
936 218251 220052 598 140275 7309538
936 218332 220483 598 143729 7383530
936 218418 220022 598 147207 7457646
936 218533 220729 598 150674 7531093
936 218443 220227 598 154254 7605487
936 218325 220378 598 157881 7679318
936 218238 220364 598 161554 7752429
936 218117 220293 598 165255 7827124
936 218385 219992 598 168553 7900642
936 218359 220082 598 172159 7975081
936 218396 220013 598 175687 8049617
936 218351 220175 598 179261 8123723
936 218454 220064 598 182717 8197492
936 218506 220927 598 186221 8271099
936 218411 220710 598 189834 8345669
936 218333 220921 598 193492 8419884
936 218316 220411 598 197099 8494388
936 218141 220141 598 200823 8569245
936 218469 220963 598 204061 8642597
936 218303 220913 598 207755 8717068
936 218405 220272 598 211229 8791638
936 218427 219983 598 214777 8866109
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
936 218326 220404 598 218427 8940293
936 218209 220393 598 222093 9013086
936 218102 220308 598 225790 9087782
936 218392 220915 598 229066 9163134
936 218400 220629 598 232669 9237613
936 218418 221040 598 236210 9312084
936 218437 220500 598 239778 9386620
936 218412 220091 598 243393 9461127
936 218273 220393 598 247081 9535375
936 218125 220285 598 250747 9608293
936 218448 220055 598 254021 9683584
936 218396 220045 598 257632 9756246
936 218246 220451 598 261331 9830494
936 218368 220556 598 264744 9904713
936 218463 220745 598 268229 9977937
931 218435 220973 598 271896 10052242
931 218423 219928 598 275487 10126797
931 218335 220421 598 279124 10200916
931 218239 220357 598 282769 10273743
931 218080 220292 598 286518 10348497
931 218372 220031 598 289792 10421955
931 218382 220053 598 293362 10496440
931 218283 220152 598 297010 10570962
931 218395 220041 598 300464 10645474
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
931 218415 220063 598 304034 10719964
933 218254 220412 600 307745 10794403
933 218249 219863 600 311330 10868756
907 218481 220498 600 314754 10942054
794 218374 221250 600 318455 11015828
649 218266 220274 600 322184 11090583
605 218553 220393 600 325545 11164588
605 218410 221124 600 329221 11238537
556 218480 220528 600 332686 11313045
704 218320 220508 618 336333 11386329
706 218362 220113 618 339757 11459257
706 218452 220024 618 343233 11533762
706 218399 220013 618 346835 11606489
706 218325 220507 618 350493 11680614
706 218179 220301 618 354198 11755470
706 218143 220310 618 357979 11830002
706 218423 220029 618 361265 11904778
706 218359 220061 618 364888 11978024
706 218421 220064 618 368413 12052464
706 218419 220034 618 371974 12127002
706 218360 220464 618 375600 12201122
706 218284 220393 618 379238 12275786
706 218200 220038 618 382912 12350452
706 218440 220076 618 386238 12423931
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
737 218232 221260 626 389933 12497799
769 218544 220262 632 393218 12572303
769 218491 220954 632 396820 12646135
765 218377 221004 632 400462 12720702
758 218458 220869 632 403937 12795088
758 218411 220356 632 407574 12869591
758 218335 220565 632 411265 12943900
758 218291 220323 632 414865 13018508
758 218131 220387 632 418574 13091621
758 218455 220868 632 421816 13166587
758 218411 220042 632 425440 13241159
758 218402 220052 632 429015 13314754
758 218434 220030 632 432542 13388325
758 218378 220108 632 436178 13462798
758 218267 220443 632 439838 13537078
758 218158 219803 632 443537 13611737
758 218462 220759 632 446768 13684545
758 218304 220589 632 450444 13758650
758 218238 220248 632 454059 13833282
758 218508 221032 632 457355 13906731
758 218411 221097 632 461011 13981268
758 218502 220088 632 464486 14055739
758 218425 220029 632 468081 14128468
758 218442 220044 632 471644 14202939
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
758 218197 219980 632 475448 14277412
758 218585 220582 632 478626 14350235
758 218362 220844 632 482336 14424181
758 218153 220397 632 486032 14497989
758 218432 220085 632 489319 14572359
759 218401 220035 633 492940 14645117
764 218249 221189 636 496579 14718804
764 218550 220378 636 499875 14792815
764 218434 220757 636 503478 14866765
764 218419 220028 636 507028 14940308
764 218416 220043 636 510720 15013964
764 218396 220430 636 514377 15088108
764 218244 220335 636 518083 15162735
764 218234 219856 636 521683 15236999
764 218406 220072 636 525067 15310945
764 218309 221065 636 528692 15384520
764 218250 220602 636 532300 15458898
764 218500 221032 636 535616 15532409
764 218402 220849 636 539211 15606981
764 218438 220475 636 542762 15681424
764 218447 220000 636 546312 15755963
763 218384 220457 637 549924 15828821
764 218246 220435 637 553643 15902955
764 218192 220381 637 557403 15977566
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
765 218439 220074 638 560815 16051161
765 218395 220026 642 564490 16125937
772 218402 220052 642 568049 16200409
770 218422 220577 642 571579 16274367
770 218366 220009 642 575194 16349028
770 218386 220038 642 578754 16422937
770 218496 220983 642 582180 16496402
770 218495 221041 642 585755 16570865
770 218321 221144 642 589474 16645209
770 218189 220274 642 593186 16720032
770 218543 220914 642 596429 16793418
605 218404 220790 642 600041 16867953
773 218294 219959 661 603686 16941696
770 218391 220014 661 607162 17016224
770 218337 220410 661 610796 17090376
770 218177 220346 661 614505 17165103
770 218193 219840 661 618079 17239467
770 218423 220035 661 621415 17313220
770 218428 220163 661 625155 17387573
770 218289 220174 661 628843 17462224
770 218398 220610 661 632300 17536184
770 218390 220252 661 635867 17610815
770 218358 219976 661 639479 17684919
770 218546 220973 661 642826 17758160
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
770 218449 221230 661 646472 17832500
1113 218466 220978 710 649881 17905235
1076 218426 220949 710 653464 17979769
1081 218262 221048 710 657208 18054048
1081 218283 220346 710 660767 18128602
1081 218481 221042 710 664104 18202209
1081 218446 221045 710 667698 18276745
1081 218323 220509 710 671714 18351262
1081 218405 220088 710 675167 18424047
1081 218405 220024 710 678747 18498460
1081 218297 220388 710 682435 18572710
1081 218220 219850 710 686071 18647021
1081 218348 221302 710 689416 18719541
1081 218211 220410 710 693040 18792907
1081 218187 220338 710 696654 18866997
1081 218416 220076 710 699981 18940508
1081 218327 221285 710 703567 19013863
1081 218228 220265 710 707215 19088494
1116 218412 220030 717 710535 19160438
1114 218292 220086 717 714214 19235035
1114 218522 220497 717 717540 19308867
1114 218414 220057 717 721207 19383050
1114 218364 221101 717 724775 19456441
1114 218405 219974 717 728238 19531008
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1114 218318 220510 717 731907 19603222
1114 218221 220447 717 735563 19677888
1114 218252 219866 717 739112 19752104
1114 218459 220432 717 742471 19825615
1114 218279 220849 717 746138 19899513
1114 218162 220345 717 749783 19974000
1114 218438 220372 717 753228 20047534
1113 218353 220148 717 756893 20120166
1108 218431 220039 717 760381 20194702
1108 218378 220511 717 763952 20268693
1108 218385 221011 717 767504 20341759
1108 218467 220654 717 770926 20416167
1108 218349 220025 717 774562 20488926
1108 218271 220391 717 778220 20563143
1108 218260 219883 717 781790 20637373
1108 218455 220686 717 785130 20710614
1108 218355 220926 717 788748 20784642
1108 218282 220284 717 792401 20859209
1108 218471 220991 717 795877 20932815
1108 218350 220146 717 799583 21007268
1201 218499 220933 750 802700 21078409
1213 218649 221046 757 802700 21079123
1213 218649 221046 757 802700 21079257
1213 218649 221046 757 802700 21079259
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1213 218649 221046 757 802700 21079275
1213 218649 221046 757 802700 21079510
1213 218649 221046 757 802700 21079513
1213 218649 221046 757 802700 21079515
1213 218649 221046 757 802700 21079562
1213 218649 221046 757 802700 21079564
1213 218649 221046 757 802700 21079567
1213 218649 221046 757 802700 21079582
1213 218649 221046 757 802700 21079585
1213 218649 221046 757 802700 21079587
1213 218649 221046 757 802700 21079592
1213 218649 221046 757 802700 21079594
1213 218649 221046 757 802700 21079597
1213 218649 221108 759 802700 21079615
1215 218649 221105 759 802700 21079618
1215 218649 221105 759 802700 21079621
1215 218649 221105 759 802700 21079651
1215 218649 221105 759 802700 21079653
1215 218649 221105 759 802700 21079656
1215 218649 221105 759 802700 21079677
1215 218649 221105 759 802700 21079680
1215 218649 221105 759 802700 21079682
1215 218649 221105 759 802700 21079687
1215 218649 221105 759 802700 21079689
nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
1215 218649 221105 759 802700 21079692
1215 218649 221105 759 802700 21079696
1215 218649 221105 759 802700 21079699
1215 218649 221105 759 802700 21079701
1215 218649 221105 759 802700 21079713
1215 218649 221167 760 802700 21079720
1219 218649 221213 761 802700 21079738
1219 218649 221216 761 802700 21079777
1219 218649 221216 761 802700 21079780
1343 218649 222487 786 802700 21079801
2517 218649 225754 940 802700 21082357
2676 218650 225479 947 802700 21082932
2686 218650 225475 947 802700 21083014
2687 218650 225484 947 802700 21083327
2687 218650 225484 947 802700 21083330
2687 218650 225484 947 802700 21083332
2687 218650 225484 947 802700 21083578
2687 218650 225484 947 802700 21083580
2687 218650 225484 947 802700 21083584
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 7:15 ` Wu Fengguang
@ 2009-05-19 7:20 ` KOSAKI Motohiro
2009-05-19 7:49 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 7:20 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
> On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> > Hi
> >
> > Thanks for great works.
> >
> >
> > > SUMMARY
> > > =======
> > > The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
> > >
> > >
> > > SCENARIO
> > > ========
> > > The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> > > where 10% of the pages will be activated:
> > >
> > > for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> > > iotrace.rb --load pattern-hot-10 --play /b/sparse
> >
> >
> > Which can I download iotrace.rb?
> >
> >
> > > and monitor /proc/vmstat during the time. The test box has 2G memory.
> > >
> > >
> > > ANALYZES
> > > ========
> > >
> > > I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> > > patch, and fetched the vmstat numbers on
> > >
> > > (1) begin: shortly after the big read IO starts;
> > > (2) end: just before the big read IO stops;
> > > (3) restore: the big read IO stops and the zsh working set restored
> > >
> > > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> > > begin: 2481 2237 8694 630 0 574299
> > > end: 275 231976 233914 633 776271 20933042
> > > restore: 370 232154 234524 691 777183 20958453
> > >
> > > begin: 2434 2237 8493 629 0 574195
> > > end: 284 231970 233536 632 771918 20896129
> > > restore: 399 232218 234789 690 774526 20957909
> > >
> > > and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
> >
> > I don't think it is proper comparision.
> > you need either following comparision. otherwise we insert many guess into the analysis.
> >
> > - 2.6.29 with and without VM_EXEC patch
> > - 2.6.30-rc4-mm with and without VM_EXEC patch
> >
> >
> > >
> > > begin: 2479 2344 9659 210 0 579643
> > > end: 284 232010 234142 260 772776 20917184
> > > restore: 379 232159 234371 301 774888 20967849
> > >
> > > The numbers show that
> > >
> > > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > > I'd attribute that improvement to the mmap readahead improvements :-)
> > >
> > > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > > That's a huge improvement - which means with the VM_EXEC protection logic,
> > > active mmap pages is pretty safe even under partially cache hot streaming IO.
> > >
> > > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > > That roughly means the active mmap pages get 20.8 more chances to get
> > > re-referenced to stay in memory.
> > >
> > > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > > dropped pages are mostly inactive ones. The patch has almost no impact in
> > > this aspect, that means it won't unnecessarily increase memory pressure.
> > > (In contrast, your 20% mmap protection ratio will keep them all, and
> > > therefore eliminate the extra 41 major faults to restore working set
> > > of zsh etc.)
>
> More results on X desktop, kernel 2.6.30-rc4-mm:
>
> nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
>
> VM_EXEC protection ON:
> begin: 9740 8920 64075 561 0 678360
> end: 768 218254 220029 565 798953 21057006
> restore: 857 218543 220987 606 799462 21075710
> restore X: 2414 218560 225344 797 799462 21080795
>
> VM_EXEC protection OFF:
> begin: 9368 5035 26389 554 0 633391
> end: 770 218449 221230 661 646472 17832500
> restore: 1113 218466 220978 710 649881 17905235
> restore X: 2687 218650 225484 947 802700 21083584
>
> The added "restore X" means after IO, switch back and forth between the urxvt
> and firefox windows to restore their working set. I cannot explain why the
> absolute nr_mapped grows larger at the end of VM_EXEC OFF case. Maybe it's
> because urxvt is the foreground window during the first run, and firefox is the
> foreground window during the second run?
>
> Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> the original size - during the streaming IO.
>
> The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> process.
hmmm.
about 100 page fault don't match Elladan's problem, I think.
perhaps We missed any addional reproduce condition?
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 7:20 ` KOSAKI Motohiro
@ 2009-05-19 7:49 ` Wu Fengguang
2009-05-19 8:06 ` KOSAKI Motohiro
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 7:49 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 03:20:19PM +0800, KOSAKI Motohiro wrote:
> > On Tue, May 19, 2009 at 12:41:38PM +0800, KOSAKI Motohiro wrote:
> > > Hi
> > >
> > > Thanks for great works.
> > >
> > >
> > > > SUMMARY
> > > > =======
> > > > The patch decreases the number of major faults from 50 to 3 during 10% cache hot reads.
> > > >
> > > >
> > > > SCENARIO
> > > > ========
> > > > The test scenario is to do 100000 pread(size=110 pages, offset=(i*100) pages),
> > > > where 10% of the pages will be activated:
> > > >
> > > > for i in `seq 0 100 10000000`; do echo $i 110; done > pattern-hot-10
> > > > iotrace.rb --load pattern-hot-10 --play /b/sparse
> > >
> > >
> > > Which can I download iotrace.rb?
> > >
> > >
> > > > and monitor /proc/vmstat during the time. The test box has 2G memory.
> > > >
> > > >
> > > > ANALYZES
> > > > ========
> > > >
> > > > I carried out two runs on fresh booted console mode 2.6.29 with the VM_EXEC
> > > > patch, and fetched the vmstat numbers on
> > > >
> > > > (1) begin: shortly after the big read IO starts;
> > > > (2) end: just before the big read IO stops;
> > > > (3) restore: the big read IO stops and the zsh working set restored
> > > >
> > > > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> > > > begin: 2481 2237 8694 630 0 574299
> > > > end: 275 231976 233914 633 776271 20933042
> > > > restore: 370 232154 234524 691 777183 20958453
> > > >
> > > > begin: 2434 2237 8493 629 0 574195
> > > > end: 284 231970 233536 632 771918 20896129
> > > > restore: 399 232218 234789 690 774526 20957909
> > > >
> > > > and another run on 2.6.30-rc4-mm with the VM_EXEC logic disabled:
> > >
> > > I don't think it is proper comparision.
> > > you need either following comparision. otherwise we insert many guess into the analysis.
> > >
> > > - 2.6.29 with and without VM_EXEC patch
> > > - 2.6.30-rc4-mm with and without VM_EXEC patch
> > >
> > >
> > > >
> > > > begin: 2479 2344 9659 210 0 579643
> > > > end: 284 232010 234142 260 772776 20917184
> > > > restore: 379 232159 234371 301 774888 20967849
> > > >
> > > > The numbers show that
> > > >
> > > > - The startup pgmajfault of 2.6.30-rc4-mm is merely 1/3 that of 2.6.29.
> > > > I'd attribute that improvement to the mmap readahead improvements :-)
> > > >
> > > > - The pgmajfault increment during the file copy is 633-630=3 vs 260-210=50.
> > > > That's a huge improvement - which means with the VM_EXEC protection logic,
> > > > active mmap pages is pretty safe even under partially cache hot streaming IO.
> > > >
> > > > - when active:inactive file lru size reaches 1:1, their scan rates is 1:20.8
> > > > under 10% cache hot IO. (computed with formula Dpgdeactivate:Dpgfree)
> > > > That roughly means the active mmap pages get 20.8 more chances to get
> > > > re-referenced to stay in memory.
> > > >
> > > > - The absolute nr_mapped drops considerably to 1/9 during the big IO, and the
> > > > dropped pages are mostly inactive ones. The patch has almost no impact in
> > > > this aspect, that means it won't unnecessarily increase memory pressure.
> > > > (In contrast, your 20% mmap protection ratio will keep them all, and
> > > > therefore eliminate the extra 41 major faults to restore working set
> > > > of zsh etc.)
> >
> > More results on X desktop, kernel 2.6.30-rc4-mm:
> >
> > nr_mapped nr_active_file nr_inactive_file pgmajfault pgdeactivate pgfree
> >
> > VM_EXEC protection ON:
> > begin: 9740 8920 64075 561 0 678360
> > end: 768 218254 220029 565 798953 21057006
> > restore: 857 218543 220987 606 799462 21075710
> > restore X: 2414 218560 225344 797 799462 21080795
> >
> > VM_EXEC protection OFF:
> > begin: 9368 5035 26389 554 0 633391
> > end: 770 218449 221230 661 646472 17832500
> > restore: 1113 218466 220978 710 649881 17905235
> > restore X: 2687 218650 225484 947 802700 21083584
> >
> > The added "restore X" means after IO, switch back and forth between the urxvt
> > and firefox windows to restore their working set. I cannot explain why the
> > absolute nr_mapped grows larger at the end of VM_EXEC OFF case. Maybe it's
> > because urxvt is the foreground window during the first run, and firefox is the
> > foreground window during the second run?
> >
> > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > the original size - during the streaming IO.
> >
> > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > process.
>
> hmmm.
>
> about 100 page fault don't match Elladan's problem, I think.
> perhaps We missed any addional reproduce condition?
Elladan's case is not the point of this test.
Elladan's IO is use-once, so probably not a caching problem at all.
This test case is specifically devised to confirm whether this patch
works as expected. Conclusion: it is.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 7:49 ` Wu Fengguang
@ 2009-05-19 8:06 ` KOSAKI Motohiro
2009-05-19 8:53 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 8:06 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
> > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > > the original size - during the streaming IO.
> > >
> > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > > process.
> >
> > hmmm.
> >
> > about 100 page fault don't match Elladan's problem, I think.
> > perhaps We missed any addional reproduce condition?
>
> Elladan's case is not the point of this test.
> Elladan's IO is use-once, so probably not a caching problem at all.
>
> This test case is specifically devised to confirm whether this patch
> works as expected. Conclusion: it is.
Dejection ;-)
The number should address the patch is useful or not. confirming as expected
is not so great.
I don't think your patch is strange, but I really want to find reproduce way.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 8:06 ` KOSAKI Motohiro
@ 2009-05-19 8:53 ` Wu Fengguang
2009-05-19 12:28 ` KOSAKI Motohiro
2009-05-19 13:24 ` Rik van Riel
0 siblings, 2 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 8:53 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > > > the original size - during the streaming IO.
> > > >
> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > > > process.
> > >
> > > hmmm.
> > >
> > > about 100 page fault don't match Elladan's problem, I think.
> > > perhaps We missed any addional reproduce condition?
> >
> > Elladan's case is not the point of this test.
> > Elladan's IO is use-once, so probably not a caching problem at all.
> >
> > This test case is specifically devised to confirm whether this patch
> > works as expected. Conclusion: it is.
>
> Dejection ;-)
>
> The number should address the patch is useful or not. confirming as expected
> is not so great.
OK, let's make the conclusion in this way:
The changelog analyzed the possible beneficial situation, and this
test backs that theory with real numbers, ie: it successfully stops
major faults when the active file list is slowly scanned when there
are partially cache hot streaming IO.
Another (amazing) finding of the test is, only around 1/10 mapped pages
are actively referenced in the absence of user activities.
Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
Or, shall we take the "protect active VM_EXEC mapped pages" approach,
or Christoph's "protect all mapped pages all time, unless they grow
too large" attitude? I still prefer the best effort VM_EXEC heuristics.
1) the partially cache hot streaming IO is far more likely to happen
on (file) servers. For them, evicting the 9/10 inactive mapped
pages over night should be acceptable for sysadms.
2) for use-once IO on desktop, we have Rik's active file list
protection heuristics, so nothing to worry at all.
3) for big working set small memory desktop, the active list will
still be scanned, in this situation, why not evict some of the
inactive mapped pages? If they have not been accessed for 1 minute,
they are not likely be the user focus, and the tight memory
constraint can only afford to cache the user focused working set.
Does that make sense?
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 8:53 ` Wu Fengguang
@ 2009-05-19 12:28 ` KOSAKI Motohiro
2009-05-20 1:44 ` Wu Fengguang
2009-05-19 13:24 ` Rik van Riel
1 sibling, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 12:28 UTC (permalink / raw)
To: Wu Fengguang
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
Hi
2009/5/19 Wu Fengguang <fengguang.wu@intel.com>:
> On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
>> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
>> > > > the original size - during the streaming IO.
>> > > >
>> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
>> > > > process.
>> > >
>> > > hmmm.
>> > >
>> > > about 100 page fault don't match Elladan's problem, I think.
>> > > perhaps We missed any addional reproduce condition?
>> >
>> > Elladan's case is not the point of this test.
>> > Elladan's IO is use-once, so probably not a caching problem at all.
>> >
>> > This test case is specifically devised to confirm whether this patch
>> > works as expected. Conclusion: it is.
>>
>> Dejection ;-)
>>
>> The number should address the patch is useful or not. confirming as expected
>> is not so great.
>
> OK, let's make the conclusion in this way:
>
> The changelog analyzed the possible beneficial situation, and this
> test backs that theory with real numbers, ie: it successfully stops
> major faults when the active file list is slowly scanned when there
> are partially cache hot streaming IO.
>
> Another (amazing) finding of the test is, only around 1/10 mapped pages
> are actively referenced in the absence of user activities.
>
> Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
Unfortunately, I don't reproduce again.
I don't apply your patch yet. but mapped ratio is reduced only very little.
I think smem can show which library evicted. Can you try it?
download: http://www.selenic.com/smem/
usage: ./smem -m -r --abbreviate
We can't decide 9/10 is important or not. we need know actual evicted file list.
Thanks.
> Or, shall we take the "protect active VM_EXEC mapped pages" approach,
> or Christoph's "protect all mapped pages all time, unless they grow
> too large" attitude? I still prefer the best effort VM_EXEC heuristics.
>
> 1) the partially cache hot streaming IO is far more likely to happen
> on (file) servers. For them, evicting the 9/10 inactive mapped
> pages over night should be acceptable for sysadms.
>
> 2) for use-once IO on desktop, we have Rik's active file list
> protection heuristics, so nothing to worry at all.
>
> 3) for big working set small memory desktop, the active list will
> still be scanned, in this situation, why not evict some of the
> inactive mapped pages? If they have not been accessed for 1 minute,
> they are not likely be the user focus, and the tight memory
> constraint can only afford to cache the user focused working set.
>
> Does that make sense?
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 12:28 ` KOSAKI Motohiro
@ 2009-05-20 1:44 ` Wu Fengguang
2009-05-20 1:59 ` KOSAKI Motohiro
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-20 1:44 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
[-- Attachment #1: Type: text/plain, Size: 3294 bytes --]
On Tue, May 19, 2009 at 08:28:28PM +0800, KOSAKI Motohiro wrote:
> Hi
>
> 2009/5/19 Wu Fengguang <fengguang.wu@intel.com>:
> > On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
> >> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> >> > > > the original size - during the streaming IO.
> >> > > >
> >> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> >> > > > process.
> >> > >
> >> > > hmmm.
> >> > >
> >> > > about 100 page fault don't match Elladan's problem, I think.
> >> > > perhaps We missed any addional reproduce condition?
> >> >
> >> > Elladan's case is not the point of this test.
> >> > Elladan's IO is use-once, so probably not a caching problem at all.
> >> >
> >> > This test case is specifically devised to confirm whether this patch
> >> > works as expected. Conclusion: it is.
> >>
> >> Dejection ;-)
> >>
> >> The number should address the patch is useful or not. confirming as expected
> >> is not so great.
> >
> > OK, let's make the conclusion in this way:
> >
> > The changelog analyzed the possible beneficial situation, and this
> > test backs that theory with real numbers, ie: it successfully stops
> > major faults when the active file list is slowly scanned when there
> > are partially cache hot streaming IO.
> >
> > Another (amazing) finding of the test is, only around 1/10 mapped pages
> > are actively referenced in the absence of user activities.
> >
> > Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
>
> Unfortunately, I don't reproduce again.
> I don't apply your patch yet. but mapped ratio is reduced only very little.
mapped ratio or absolute numbers? The ratio wont change much because
nr_mapped is already small.
> I think smem can show which library evicted. Can you try it?
>
> download: http://www.selenic.com/smem/
> usage: ./smem -m -r --abbreviate
Sure, but I don't see much change in its output (see attachments).
smem-console-0 is collected after fresh boot,
smem-console-1 is collected after the big IO.
> We can't decide 9/10 is important or not. we need know actual evicted file list.
Right. But what I measured is the activeness. Almost zero major page
faults means the evicted 90% mapped pages are inactive during the
long 300 seconds of IO.
Thanks,
Fengguang
> > Or, shall we take the "protect active VM_EXEC mapped pages" approach,
> > or Christoph's "protect all mapped pages all time, unless they grow
> > too large" attitude? I still prefer the best effort VM_EXEC heuristics.
> >
> > 1) the partially cache hot streaming IO is far more likely to happen
> > on (file) servers. For them, evicting the 9/10 inactive mapped
> > pages over night should be acceptable for sysadms.
> >
> > 2) for use-once IO on desktop, we have Rik's active file list
> > protection heuristics, so nothing to worry at all.
> >
> > 3) for big working set small memory desktop, the active list will
> > still be scanned, in this situation, why not evict some of the
> > inactive mapped pages? If they have not been accessed for 1 minute,
> > they are not likely be the user focus, and the tight memory
> > constraint can only afford to cache the user focused working set.
> >
> > Does that make sense?
[-- Attachment #2: smem-console-0 --]
[-- Type: text/plain, Size: 2376 bytes --]
Map PIDs AVGPSS PSS
[heap] 2 1.5M 2.9M
<anonymous> 2 538.0K 1.1M
/usr/bin/python2.5 1 1.0M 1.0M
/bin/zsh4 1 592.0K 592.0K
/usr/lib/zsh/4.3.9/zsh/zle.so 1 216.0K 216.0K
/lib/libncursesw.so.5.7 1 156.0K 156.0K
/lib/libc-2.9.so 2 65.0K 130.0K
[stack] 2 62.0K 124.0K
/usr/lib/zsh/4.3.9/zsh/complete.so 1 56.0K 56.0K
/usr/lib/locale/locale-archive 2 28.0K 56.0K
/usr/lib/python2.5/lib-dynload/operator. 1 32.0K 32.0K
/lib/libm-2.9.so 2 15.0K 30.0K
/usr/lib/zsh/4.3.9/zsh/complist.so 1 28.0K 28.0K
/lib/ld-2.9.so 2 13.0K 26.0K
/usr/lib/zsh/4.3.9/zsh/parameter.so 1 24.0K 24.0K
/usr/lib/python2.5/lib-dynload/_struct.s 1 24.0K 24.0K
/usr/lib/zsh/4.3.9/zsh/zutil.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/time.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/strop.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/_locale.s 1 20.0K 20.0K
/lib/libpthread-2.9.so 1 18.0K 18.0K
/lib/libdl-2.9.so 2 9.0K 18.0K
/usr/lib/zsh/4.3.9/zsh/rlimits.so 1 16.0K 16.0K
/lib/libcap.so.2.11 1 16.0K 16.0K
/lib/libattr.so.1.1.0 1 16.0K 16.0K
/usr/lib/zsh/4.3.9/zsh/terminfo.so 1 12.0K 12.0K
/usr/lib/python2.5/lib-dynload/grp.so 1 12.0K 12.0K
/lib/libutil-2.9.so 1 11.0K 11.0K
/lib/libnss_nis-2.9.so 1 11.0K 11.0K
/lib/libnss_files-2.9.so 1 10.0K 10.0K
/lib/libnss_compat-2.9.so 1 10.0K 10.0K
/lib/libnsl-2.9.so 1 10.0K 10.0K
/usr/lib/gconv/gconv-modules.cache 1 5.0K 5.0K
[vsyscall] 2 0 0
[vdso] 2 0 0
[-- Attachment #3: smem-console-1 --]
[-- Type: text/plain, Size: 2376 bytes --]
Map PIDs AVGPSS PSS
[heap] 2 1.5M 2.9M
<anonymous> 2 538.0K 1.1M
/usr/bin/python2.5 1 1.0M 1.0M
/bin/zsh4 1 496.0K 496.0K
/lib/libc-2.9.so 2 180.0K 360.0K
[stack] 2 60.0K 120.0K
/lib/ld-2.9.so 2 58.0K 116.0K
/usr/lib/zsh/4.3.9/zsh/zle.so 1 112.0K 112.0K
/lib/libncursesw.so.5.7 1 56.0K 56.0K
/usr/lib/locale/locale-archive 2 26.0K 52.0K
/lib/libpthread-2.9.so 1 48.0K 48.0K
/lib/libm-2.9.so 2 21.0K 42.0K
/usr/lib/python2.5/lib-dynload/operator. 1 32.0K 32.0K
/usr/lib/zsh/4.3.9/zsh/complete.so 1 24.0K 24.0K
/usr/lib/python2.5/lib-dynload/_struct.s 1 24.0K 24.0K
/lib/libdl-2.9.so 2 12.0K 24.0K
/usr/lib/python2.5/lib-dynload/time.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/strop.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/_locale.s 1 20.0K 20.0K
/lib/libutil-2.9.so 1 16.0K 16.0K
/usr/lib/python2.5/lib-dynload/grp.so 1 12.0K 12.0K
/lib/libcap.so.2.11 1 12.0K 12.0K
/lib/libnss_compat-2.9.so 1 9.0K 9.0K
/usr/lib/zsh/4.3.9/zsh/zutil.so 1 8.0K 8.0K
/usr/lib/zsh/4.3.9/zsh/rlimits.so 1 8.0K 8.0K
/lib/libnss_nis-2.9.so 1 8.0K 8.0K
/lib/libnss_files-2.9.so 1 8.0K 8.0K
/lib/libnsl-2.9.so 1 8.0K 8.0K
/usr/lib/zsh/4.3.9/zsh/terminfo.so 1 4.0K 4.0K
/usr/lib/zsh/4.3.9/zsh/parameter.so 1 4.0K 4.0K
/usr/lib/zsh/4.3.9/zsh/complist.so 1 4.0K 4.0K
/lib/libattr.so.1.1.0 1 4.0K 4.0K
[vsyscall] 2 0 0
[vdso] 2 0 0
/usr/lib/gconv/gconv-modules.cache 1 0 0
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 1:44 ` Wu Fengguang
@ 2009-05-20 1:59 ` KOSAKI Motohiro
2009-05-20 2:31 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-20 1:59 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
> On Tue, May 19, 2009 at 08:28:28PM +0800, KOSAKI Motohiro wrote:
> > Hi
> >
> > 2009/5/19 Wu Fengguang <fengguang.wu@intel.com>:
> > > On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
> > >> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > >> > > > the original size - during the streaming IO.
> > >> > > >
> > >> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > >> > > > process.
> > >> > >
> > >> > > hmmm.
> > >> > >
> > >> > > about 100 page fault don't match Elladan's problem, I think.
> > >> > > perhaps We missed any addional reproduce condition?
> > >> >
> > >> > Elladan's case is not the point of this test.
> > >> > Elladan's IO is use-once, so probably not a caching problem at all.
> > >> >
> > >> > This test case is specifically devised to confirm whether this patch
> > >> > works as expected. Conclusion: it is.
> > >>
> > >> Dejection ;-)
> > >>
> > >> The number should address the patch is useful or not. confirming as expected
> > >> is not so great.
> > >
> > > OK, let's make the conclusion in this way:
> > >
> > > The changelog analyzed the possible beneficial situation, and this
> > > test backs that theory with real numbers, ie: it successfully stops
> > > major faults when the active file list is slowly scanned when there
> > > are partially cache hot streaming IO.
> > >
> > > Another (amazing) finding of the test is, only around 1/10 mapped pages
> > > are actively referenced in the absence of user activities.
> > >
> > > Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
> >
> > Unfortunately, I don't reproduce again.
> > I don't apply your patch yet. but mapped ratio is reduced only very little.
>
> mapped ratio or absolute numbers? The ratio wont change much because
> nr_mapped is already small.
My box is running Fedora 10 initlevel 5 (GNOME desktop).
many GNOME component is mapped very many process (likes >50).
Thus, these page aren't dropped by typical any workload.
> > I think smem can show which library evicted. Can you try it?
> >
> > download: http://www.selenic.com/smem/
> > usage: ./smem -m -r --abbreviate
>
> Sure, but I don't see much change in its output (see attachments).
>
> smem-console-0 is collected after fresh boot,
> smem-console-1 is collected after the big IO.
hmmmm, your result has following characatistics.
- no graphics component
- very few mapped library
(it is almost only zsh library)
Can you try test on X environment?
> > We can't decide 9/10 is important or not. we need know actual evicted file list.
>
> Right. But what I measured is the activeness. Almost zero major page
> faults means the evicted 90% mapped pages are inactive during the
> long 300 seconds of IO.
Agreed.
IOW, I don't think your test environment is typical desktop...
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 1:59 ` KOSAKI Motohiro
@ 2009-05-20 2:31 ` Wu Fengguang
2009-05-20 2:58 ` KOSAKI Motohiro
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-20 2:31 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Christoph Lameter, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Peter Zijlstra, Rik van Riel, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]
On Wed, May 20, 2009 at 09:59:05AM +0800, KOSAKI Motohiro wrote:
> > On Tue, May 19, 2009 at 08:28:28PM +0800, KOSAKI Motohiro wrote:
> > > Hi
> > >
> > > 2009/5/19 Wu Fengguang <fengguang.wu@intel.com>:
> > > > On Tue, May 19, 2009 at 04:06:35PM +0800, KOSAKI Motohiro wrote:
> > > >> > > > Like the console mode, the absolute nr_mapped drops considerably - to 1/13 of
> > > >> > > > the original size - during the streaming IO.
> > > >> > > >
> > > >> > > > The delta of pgmajfault is 3 vs 107 during IO, or 236 vs 393 during the whole
> > > >> > > > process.
> > > >> > >
> > > >> > > hmmm.
> > > >> > >
> > > >> > > about 100 page fault don't match Elladan's problem, I think.
> > > >> > > perhaps We missed any addional reproduce condition?
> > > >> >
> > > >> > Elladan's case is not the point of this test.
> > > >> > Elladan's IO is use-once, so probably not a caching problem at all.
> > > >> >
> > > >> > This test case is specifically devised to confirm whether this patch
> > > >> > works as expected. Conclusion: it is.
> > > >>
> > > >> Dejection ;-)
> > > >>
> > > >> The number should address the patch is useful or not. confirming as expected
> > > >> is not so great.
> > > >
> > > > OK, let's make the conclusion in this way:
> > > >
> > > > The changelog analyzed the possible beneficial situation, and this
> > > > test backs that theory with real numbers, ie: it successfully stops
> > > > major faults when the active file list is slowly scanned when there
> > > > are partially cache hot streaming IO.
> > > >
> > > > Another (amazing) finding of the test is, only around 1/10 mapped pages
> > > > are actively referenced in the absence of user activities.
> > > >
> > > > Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
> > >
> > > Unfortunately, I don't reproduce again.
> > > I don't apply your patch yet. but mapped ratio is reduced only very little.
> >
> > mapped ratio or absolute numbers? The ratio wont change much because
> > nr_mapped is already small.
>
> My box is running Fedora 10 initlevel 5 (GNOME desktop).
>
> many GNOME component is mapped very many process (likes >50).
> Thus, these page aren't dropped by typical any workload.
Yeah, that's possible (but sounds bloated in regard of active
working set size).
> > > I think smem can show which library evicted. Can you try it?
> > >
> > > download: http://www.selenic.com/smem/
> > > usage: ./smem -m -r --abbreviate
> >
> > Sure, but I don't see much change in its output (see attachments).
> >
> > smem-console-0 is collected after fresh boot,
> > smem-console-1 is collected after the big IO.
>
> hmmmm, your result has following characatistics.
>
> - no graphics component
> - very few mapped library
> (it is almost only zsh library)
>
> Can you try test on X environment?
Sure, see the attached smem-x-0/1. This time we see sufficient differences.
> > > We can't decide 9/10 is important or not. we need know actual evicted file list.
> >
> > Right. But what I measured is the activeness. Almost zero major page
> > faults means the evicted 90% mapped pages are inactive during the
> > long 300 seconds of IO.
>
> Agreed.
> IOW, I don't think your test environment is typical desktop...
Kind of :) It's fluxbox + terminal + firefox, a bare desktop for
testing things out.
[-- Attachment #2: smem-x-1 --]
[-- Type: text/plain, Size: 13926 bytes --]
Map PIDs AVGPSS PSS
[heap] 15 2.7M 40.5M
<anonymous> 15 390.0K 5.7M
/usr/lib/xulrunner-1.9/libxul.so 1 2.1M 2.1M
/usr/bin/python2.5 1 1.0M 1.0M
/lib/libc-2.9.so 15 43.0K 649.0K
[stack] 15 38.0K 584.0K
/bin/zsh4 3 176.0K 528.0K
/usr/lib/libX11.so.6.2.0 7 40.0K 284.0K
/usr/lib/libmozjs.so.1d 1 232.0K 232.0K
/usr/lib/libscim-1.0.so.8.2.3 3 76.0K 228.0K
/lib/ld-2.9.so 15 14.0K 220.0K
/usr/lib/libstdc++.so.6.0.10 5 42.0K 211.0K
/usr/lib/zsh/4.3.9/zsh/zle.so 3 58.0K 176.0K
/usr/lib/libORBit-2.so.0.1.0 2 88.0K 176.0K
/usr/lib/libsqlite3.so.0.8.6 1 160.0K 160.0K
/lib/libdl-2.9.so 15 8.0K 128.0K
/usr/bin/fluxbox 1 120.0K 120.0K
/lib/libm-2.9.so 10 10.0K 109.0K
/lib/libpthread-2.9.so 8 13.0K 105.0K
/SYSV00000000 2 52.0K 104.0K
/usr/lib/libfreetype.so.6.3.18 4 24.0K 96.0K
/lib/libnss_compat-2.9.so 11 8.0K 94.0K
/lib/libncursesw.so.5.7 3 30.0K 92.0K
/usr/lib/libgtk-x11-2.0.so.0.1600.1 2 44.0K 88.0K
/lib/libnss_nis-2.9.so 11 8.0K 88.0K
/lib/libnss_files-2.9.so 11 8.0K 88.0K
/lib/libnsl-2.9.so 11 8.0K 88.0K
/usr/lib/nss/libnssckbi.so 1 80.0K 80.0K
/usr/lib/libxml2.so.2.6.32 2 40.0K 80.0K
/usr/lib/libnspr4.so.0d 1 76.0K 76.0K
/usr/lib/libglib-2.0.so.0.2000.1 4 17.0K 68.0K
/usr/lib/libbonobo-2.so.0.0.0 1 68.0K 68.0K
/usr/lib/locale/locale-archive 10 5.0K 52.0K
/usr/lib/libgdk-x11-2.0.so.0.1600.1 2 26.0K 52.0K
/usr/lib/libgconf-2.so.4.1.5 2 25.0K 50.0K
/usr/lib/libdirectfb-1.2.so.0.7.0 3 16.0K 48.0K
/usr/lib/libgnutls.so.26.11.5 1 44.0K 44.0K
/usr/lib/libgobject-2.0.so.0.2000.1 4 10.0K 41.0K
/usr/lib/zsh/4.3.9/zsh/complete.so 3 13.0K 40.0K
/usr/lib/libexpat.so.1.5.2 5 8.0K 40.0K
/usr/lib/libperl.so.5.10.0 1 36.0K 36.0K
/usr/lib/libpango-1.0.so.0.2400.0 3 12.0K 36.0K
/usr/lib/libnss3.so.1d 1 36.0K 36.0K
/usr/lib/libcairo.so.2.10800.6 3 12.0K 36.0K
/usr/bin/urxvt 1 36.0K 36.0K
/usr/lib/libxcb.so.1.1.0 7 5.0K 35.0K
/usr/lib/python2.5/lib-dynload/operator. 1 32.0K 32.0K
/usr/lib/libfontconfig.so.1.3.0 4 8.0K 32.0K
/lib/libselinux.so.1 4 8.0K 32.0K
/usr/lib/libpixman-1.so.0.12.0 3 10.0K 30.0K
/usr/lib/libXdmcp.so.6.0.0 7 4.0K 28.0K
/usr/lib/libXau.so.6.0.0 7 4.0K 28.0K
/lib/librt-2.9.so 3 8.0K 25.0K
/usr/lib/python2.5/lib-dynload/_struct.s 1 24.0K 24.0K
/usr/lib/libtiff.so.4.2.1 2 12.0K 24.0K
/usr/lib/libgnomeui-2.so.0.2000.1 1 24.0K 24.0K
/usr/lib/libgio-2.0.so.0.2000.1 3 8.0K 24.0K
/usr/lib/libatk-1.0.so.0.2209.1 2 12.0K 24.0K
/usr/lib/libXt.so.6.0.0 1 24.0K 24.0K
/usr/lib/gnome-vfs-2.0/modules/libfile.s 1 24.0K 24.0K
/lib/libutil-2.9.so 2 12.0K 24.0K
/lib/libgcc_s.so.1 6 4.0K 24.0K
/bin/bash 1 24.0K 24.0K
/usr/lib/python2.5/lib-dynload/time.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/strop.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/_locale.s 1 20.0K 20.0K
/usr/lib/libnssutil3.so.1d 1 20.0K 20.0K
/usr/lib/libgnomevfs-2.so.0.2200.0 1 20.0K 20.0K
/usr/lib/libbonoboui-2.so.0.0.0 1 20.0K 20.0K
/lib/libncurses.so.5.7 1 20.0K 20.0K
/usr/lib/zsh/4.3.9/zsh/zutil.so 3 5.0K 16.0K
/usr/lib/zsh/4.3.9/zsh/rlimits.so 3 5.0K 16.0K
/usr/lib/scim-1.0/scim-panel-gtk 1 16.0K 16.0K
/usr/lib/libz.so.1.2.3.3 4 4.0K 16.0K
/usr/lib/libsmime3.so.1d 1 16.0K 16.0K
/usr/lib/libpng12.so.0.27.0 4 4.0K 16.0K
/usr/lib/libpcre.so.3.12.1 4 4.0K 16.0K
/usr/lib/libgsf-1.so.114.0.12 1 16.0K 16.0K
/usr/lib/libgmodule-2.0.so.0.2000.1 4 4.0K 16.0K
/usr/lib/libgcrypt.so.11.5.2 1 16.0K 16.0K
/usr/lib/libcroco-0.6.so.3.0.1 1 16.0K 16.0K
/usr/lib/libbonobo-activation.so.4.0.0 1 16.0K 16.0K
/usr/lib/libaudiofile.so.0.0.2 1 16.0K 16.0K
/usr/lib/libXrender.so.1.3.0 4 4.0K 16.0K
/usr/lib/libXfixes.so.3.1.0 4 4.0K 16.0K
/usr/lib/libXext.so.6.4.0 4 4.0K 16.0K
/usr/lib/libXcursor.so.1.0.2 4 4.0K 16.0K
/usr/lib/libAfterImage.so.0.99 1 16.0K 16.0K
/usr/lib/iceweasel/components/libbrowser 1 16.0K 16.0K
/lib/libcap.so.2.11 3 5.0K 16.0K
/lib/libbz2.so.1.0.4 2 8.0K 16.0K
/lib/libattr.so.1.1.0 4 4.0K 16.0K
/usr/lib/libgthread-2.0.so.0.2000.1 3 5.0K 15.0K
/usr/lib/libgconf2-4/gconfd-2 1 14.0K 14.0K
/usr/lib/libdbus-1.so.3.4.0 1 13.0K 13.0K
/usr/lib/zsh/4.3.9/zsh/terminfo.so 3 4.0K 12.0K
/usr/lib/zsh/4.3.9/zsh/parameter.so 3 4.0K 12.0K
/usr/lib/zsh/4.3.9/zsh/computil.so 1 12.0K 12.0K
/usr/lib/zsh/4.3.9/zsh/complist.so 3 4.0K 12.0K
/usr/lib/scim-1.0/1.4.0/IMEngine/pinyin. 1 12.0K 12.0K
/usr/lib/scim-1.0/1.4.0/FrontEnd/x11.so 1 12.0K 12.0K
/usr/lib/python2.5/lib-dynload/grp.so 1 12.0K 12.0K
/usr/lib/perl/5.10.0/auto/POSIX/POSIX.so 1 12.0K 12.0K
/usr/lib/libxcb-render.so.0.0.0 3 4.0K 12.0K
/usr/lib/libxcb-render-util.so.0.0.0 3 4.0K 12.0K
/usr/lib/libssl3.so.1d 1 12.0K 12.0K
/usr/lib/libpangoft2-1.0.so.0.2400.0 3 4.0K 12.0K
/usr/lib/libpangocairo-1.0.so.0.2400.0 3 4.0K 12.0K
/usr/lib/libjpeg.so.62.0.0 3 4.0K 12.0K
/usr/lib/libid3tag.so.0.3.0 1 12.0K 12.0K
/usr/lib/libhunspell-1.2.so.0.0.0 1 12.0K 12.0K
/usr/lib/libgdk_pixbuf-2.0.so.0.1600.1 3 4.0K 12.0K
/usr/lib/libfusion-1.2.so.0.7.0 3 4.0K 12.0K
/usr/lib/libdirect-1.2.so.0.7.0 3 4.0K 12.0K
/usr/lib/libXrandr.so.2.2.0 3 4.0K 12.0K
/usr/lib/libXinerama.so.1.0.0 3 4.0K 12.0K
/usr/lib/libSM.so.6.0.0 3 4.0K 12.0K
/usr/lib/libICE.so.6.3.0 3 4.0K 12.0K
/usr/lib/libdbus-glib-1.so.2.1.0 1 10.0K 10.0K
/usr/lib/xulrunner-1.9/components/libimg 1 8.0K 8.0K
/usr/lib/scim-1.0/1.4.0/Config/simple.so 2 4.0K 8.0K
/usr/lib/pango/1.6.0/modules/pango-basic 2 4.0K 8.0K
/usr/lib/nss/libsoftokn3.so 1 8.0K 8.0K
/usr/lib/nss/libfreebl3.so 1 8.0K 8.0K
/usr/lib/libscim-x11utils-1.0.so.8.2.3 2 4.0K 8.0K
/usr/lib/librsvg-2.so.2.22.3 1 8.0K 8.0K
/usr/lib/liblcms.so.1.0.16 1 8.0K 8.0K
/usr/lib/libgnomecanvas-2.so.0.2001.0 1 8.0K 8.0K
/usr/lib/libgnome-2.so.0.1999.2 1 8.0K 8.0K
/usr/lib/libgif.so.4.1.6 2 4.0K 8.0K
/usr/lib/libXi.so.6.0.0 2 4.0K 8.0K
/usr/lib/libXft.so.2.1.2 2 4.0K 8.0K
/usr/lib/libXdamage.so.1.1.0 2 4.0K 8.0K
/usr/lib/libXcomposite.so.1.0.0 2 4.0K 8.0K
/usr/lib/libORBitCosNaming-2.so.0.1.0 1 8.0K 8.0K
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbu 2 4.0K 8.0K
/usr/lib/gconv/UTF-16.so 1 8.0K 8.0K
/usr/lib/gconv/ISO8859-1.so 1 8.0K 8.0K
/usr/bin/dbus-daemon 1 8.0K 8.0K
/lib/libresolv-2.9.so 1 8.0K 8.0K
/lib/libnss_dns-2.9.so 1 8.0K 8.0K
/lib/libcrypt-2.9.so 1 8.0K 8.0K
/usr/lib/libgconf2-4/2/libgconfbackend-x 1 6.0K 6.0K
/usr/lib/xulrunner-1.9/xulrunner-stub 1 4.0K 4.0K
/usr/lib/xulrunner-1.9/libxpcom.so 1 4.0K 4.0K
/usr/lib/xulrunner-1.9/components/libnkg 1 4.0K 4.0K
/usr/lib/xulrunner-1.9/components/libmoz 1 4.0K 4.0K
/usr/lib/xulrunner-1.9/components/libdbu 1 4.0K 4.0K
/usr/lib/scim-1.0/scim-launcher 1 4.0K 4.0K
/usr/lib/scim-1.0/scim-helper-manager 1 4.0K 4.0K
/usr/lib/perl/5.10.0/auto/List/Util/Util 1 4.0K 4.0K
/usr/lib/perl/5.10.0/auto/Fcntl/Fcntl.so 1 4.0K 4.0K
/usr/lib/nss/libnssdbm3.so 1 4.0K 4.0K
/usr/lib/libtasn1.so.3.0.16 1 4.0K 4.0K
/usr/lib/libstartup-notification-1.so.0. 1 4.0K 4.0K
/usr/lib/libscim-gtkutils-1.0.so.8.2.3 1 4.0K 4.0K
/usr/lib/libplds4.so.0d 1 4.0K 4.0K
/usr/lib/libplc4.so.0d 1 4.0K 4.0K
/usr/lib/libgpg-error.so.0.3.0 1 4.0K 4.0K
/usr/lib/libgnome-keyring.so.0.1.1 1 4.0K 4.0K
/usr/lib/libgailutil.so.18.0.1 1 4.0K 4.0K
/usr/lib/libfam.so.0.0.0 1 4.0K 4.0K
/usr/lib/libesd.so.0.2.36 1 4.0K 4.0K
/usr/lib/libavahi-glib.so.1.0.1 1 4.0K 4.0K
/usr/lib/libavahi-common.so.3.5.0 1 4.0K 4.0K
/usr/lib/libavahi-client.so.3.2.4 1 4.0K 4.0K
/usr/lib/libart_lgpl_2.so.2.3.20 1 4.0K 4.0K
/usr/lib/libXpm.so.4.11.0 1 4.0K 4.0K
/usr/lib/libImlib2.so.1.4.0 1 4.0K 4.0K
/usr/lib/libAfterBase.so.0.99 1 4.0K 4.0K
/usr/lib/imlib2/loaders/zlib.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/xpm.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/tiff.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/tga.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/pnm.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/png.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/lbm.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/jpeg.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/id3.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/gif.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/bz2.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/bmp.so 1 4.0K 4.0K
/usr/lib/imlib2/loaders/argb.so 1 4.0K 4.0K
/usr/lib/iceweasel/components/libbrowser 1 4.0K 4.0K
/usr/lib/gtk-2.0/2.10.0/immodules/im-xim 1 4.0K 4.0K
/usr/bin/xinit 1 4.0K 4.0K
/usr/bin/dbus-launch 1 4.0K 4.0K
/lib/libpopt.so.0.0.0 1 4.0K 4.0K
/lib/libnss_mdns4_minimal.so.2 1 4.0K 4.0K
/lib/libnss_mdns4.so.2 1 4.0K 4.0K
/lib/libacl.so.1.1.0 1 4.0K 4.0K
[vsyscall] 15 0 0
[vdso] 15 0 0
/var/cache/fontconfig/e13b20fdb08344e0e6 4 0 0
/var/cache/fontconfig/de156ccd2eddbdc19d 4 0 0
/var/cache/fontconfig/99e8ed0e538f840c56 4 0 0
/var/cache/fontconfig/945677eb7aeaf62f1d 4 0 0
/var/cache/fontconfig/6d41288fd70b0be22e 4 0 0
/var/cache/fontconfig/0fafd173547752dce4 4 0 0
/var/cache/fontconfig/089dead882dea3570f 4 0 0
/usr/share/mime/mime.cache 1 0 0
/usr/share/fonts/truetype/ttf-dejavu/Dej 1 0 0
/usr/share/fonts/truetype/ttf-bitstream- 1 0 0
/usr/share/fonts/truetype/ttf-bitstream- 2 0 0
/usr/share/fonts/truetype/ttf-bitstream- 1 0 0
/usr/share/fonts/X11/Type1/c0583bt_.pfb 1 0 0
/usr/share/fonts/X11/Type1/c0419bt_.pfb 2 0 0
/usr/share/fluxbox/nls/en_US.UTF-8/fluxb 1 0 0
/usr/lib/gconv/gconv-modules.cache 6 0 0
/home/wfg/.fontconfig/cabbd14511b9e8a55e 4 0 0
[-- Attachment #3: smem-x-0 --]
[-- Type: text/plain, Size: 13860 bytes --]
Map PIDs AVGPSS PSS
[heap] 15 2.3M 35.2M
/usr/lib/xulrunner-1.9/libxul.so 1 11.0M 11.0M
<anonymous> 15 390.0K 5.7M
/usr/lib/libgtk-x11-2.0.so.0.1600.1 2 934.0K 1.8M
/usr/lib/libperl.so.5.10.0 1 1.2M 1.2M
/usr/bin/python2.5 1 1.0M 1.0M
/usr/bin/fluxbox 1 1000.0K 1000.0K
/usr/lib/libX11.so.6.2.0 7 114.0K 798.0K
/usr/lib/libstdc++.so.6.0.10 5 143.0K 717.0K
/usr/lib/libscim-1.0.so.8.2.3 3 227.0K 682.0K
/bin/zsh4 3 215.0K 647.0K
/lib/libc-2.9.so 15 40.0K 613.0K
[stack] 15 39.0K 588.0K
/usr/lib/libmozjs.so.1d 1 556.0K 556.0K
/usr/lib/libnss3.so.1d 1 528.0K 528.0K
/usr/lib/libgdk-x11-2.0.so.0.1600.1 2 250.0K 500.0K
/bin/bash 1 460.0K 460.0K
/usr/lib/libfreetype.so.6.3.18 4 108.0K 433.0K
/usr/lib/libsqlite3.so.0.8.6 1 412.0K 412.0K
/usr/lib/nss/libnssckbi.so 1 384.0K 384.0K
/usr/bin/urxvt 1 364.0K 364.0K
/usr/lib/libcairo.so.2.10800.6 3 109.0K 329.0K
/usr/lib/libbonobo-2.so.0.0.0 1 312.0K 312.0K
/usr/lib/zsh/4.3.9/zsh/zle.so 3 103.0K 311.0K
/usr/lib/libORBit-2.so.0.1.0 2 155.0K 310.0K
/usr/lib/libgnomeui-2.so.0.2000.1 1 308.0K 308.0K
/usr/lib/libglib-2.0.so.0.2000.1 4 70.0K 283.0K
/usr/lib/libpango-1.0.so.0.2400.0 3 92.0K 277.0K
/usr/lib/libxml2.so.2.6.32 2 126.0K 252.0K
/usr/lib/libgnomevfs-2.so.0.2200.0 1 244.0K 244.0K
/lib/libm-2.9.so 10 24.0K 240.0K
/lib/libncursesw.so.5.7 3 65.0K 195.0K
/usr/lib/libnspr4.so.0d 1 192.0K 192.0K
/usr/lib/libgnutls.so.26.11.5 1 180.0K 180.0K
/usr/lib/scim-1.0/1.4.0/FrontEnd/x11.so 1 172.0K 172.0K
/usr/lib/libfontconfig.so.1.3.0 4 41.0K 166.0K
/usr/lib/libgio-2.0.so.0.2000.1 3 52.0K 158.0K
/usr/lib/libbonoboui-2.so.0.0.0 1 156.0K 156.0K
/lib/ld-2.9.so 15 10.0K 156.0K
/usr/lib/zsh/4.3.9/zsh/complete.so 3 51.0K 153.0K
/usr/lib/libgobject-2.0.so.0.2000.1 4 37.0K 148.0K
/usr/lib/libpng12.so.0.27.0 4 36.0K 146.0K
/usr/lib/libgconf-2.so.4.1.5 2 73.0K 146.0K
/usr/lib/nss/libsoftokn3.so 1 128.0K 128.0K
/usr/lib/scim-1.0/1.4.0/IMEngine/pinyin. 1 124.0K 124.0K
/usr/lib/libexpat.so.1.5.2 5 24.0K 124.0K
/lib/libdl-2.9.so 15 8.0K 120.0K
/usr/lib/libdirectfb-1.2.so.0.7.0 3 39.0K 119.0K
/usr/lib/libpangoft2-1.0.so.0.2400.0 3 38.0K 114.0K
/usr/lib/scim-1.0/scim-panel-gtk 1 112.0K 112.0K
/usr/lib/iceweasel/components/libbrowser 1 108.0K 108.0K
/usr/lib/libXt.so.6.0.0 1 104.0K 104.0K
/SYSV00000000 2 52.0K 104.0K
/lib/libnss_files-2.9.so 11 9.0K 99.0K
/usr/lib/locale/locale-archive 10 9.0K 97.0K
/usr/lib/libImlib2.so.1.4.0 1 96.0K 96.0K
/usr/lib/libAfterImage.so.0.99 1 96.0K 96.0K
/lib/libncurses.so.5.7 1 96.0K 96.0K
/lib/libpthread-2.9.so 8 11.0K 95.0K
/lib/libnss_nis-2.9.so 11 8.0K 94.0K
/lib/libnss_compat-2.9.so 11 8.0K 94.0K
/lib/libnsl-2.9.so 11 8.0K 94.0K
/usr/lib/libbonobo-activation.so.4.0.0 1 92.0K 92.0K
/usr/lib/libxcb.so.1.1.0 7 12.0K 89.0K
/usr/lib/libgdk_pixbuf-2.0.so.0.1600.1 3 29.0K 89.0K
/usr/lib/nss/libnssdbm3.so 1 88.0K 88.0K
/usr/lib/libnssutil3.so.1d 1 84.0K 84.0K
/usr/lib/libgsf-1.so.114.0.12 1 84.0K 84.0K
/usr/lib/libatk-1.0.so.0.2209.1 2 42.0K 84.0K
/usr/share/fonts/truetype/ttf-dejavu/Dej 1 80.0K 80.0K
/usr/lib/libssl3.so.1d 1 80.0K 80.0K
/usr/lib/libpixman-1.so.0.12.0 3 26.0K 79.0K
/usr/lib/libgnome-2.so.0.1999.2 1 76.0K 76.0K
/usr/lib/libz.so.1.2.3.3 4 18.0K 75.0K
/usr/lib/libXft.so.2.1.2 2 36.0K 72.0K
/usr/bin/dbus-daemon 1 70.0K 70.0K
/usr/lib/libsmime3.so.1d 1 68.0K 68.0K
/usr/lib/perl/5.10.0/auto/POSIX/POSIX.so 1 64.0K 64.0K
/usr/lib/libcroco-0.6.so.3.0.1 1 64.0K 64.0K
/usr/lib/libtiff.so.4.2.1 2 30.0K 60.0K
/usr/lib/libgnomecanvas-2.so.0.2001.0 1 60.0K 60.0K
/usr/lib/nss/libfreebl3.so 1 56.0K 56.0K
/usr/lib/libhunspell-1.2.so.0.0.0 1 56.0K 56.0K
/usr/lib/libgcrypt.so.11.5.2 1 52.0K 52.0K
/usr/lib/libXpm.so.4.11.0 1 52.0K 52.0K
/usr/lib/gnome-vfs-2.0/modules/libfile.s 1 52.0K 52.0K
/usr/lib/libXext.so.6.4.0 4 12.0K 50.0K
/usr/lib/libpangocairo-1.0.so.0.2400.0 3 16.0K 49.0K
/usr/lib/xulrunner-1.9/components/libimg 1 48.0K 48.0K
/usr/lib/librsvg-2.so.2.22.3 1 48.0K 48.0K
/usr/lib/libaudiofile.so.0.0.2 1 48.0K 48.0K
/usr/lib/libAfterBase.so.0.99 1 48.0K 48.0K
/lib/libselinux.so.1 4 12.0K 48.0K
/usr/lib/libXrender.so.1.3.0 4 11.0K 45.0K
/usr/share/fonts/truetype/ttf-bitstream- 1 44.0K 44.0K
/usr/share/fonts/truetype/ttf-bitstream- 1 44.0K 44.0K
/usr/lib/zsh/4.3.9/zsh/computil.so 1 44.0K 44.0K
/usr/lib/liblcms.so.1.0.16 1 44.0K 44.0K
/usr/lib/libid3tag.so.0.3.0 1 44.0K 44.0K
/lib/libresolv-2.9.so 1 44.0K 44.0K
/usr/lib/libICE.so.6.3.0 3 14.0K 43.0K
/home/wfg/.fontconfig/cabbd14511b9e8a55e 4 10.0K 42.0K
/usr/share/fonts/X11/Type1/c0583bt_.pfb 1 40.0K 40.0K
/usr/share/fonts/X11/Type1/c0419bt_.pfb 2 20.0K 40.0K
/usr/lib/libscim-gtkutils-1.0.so.8.2.3 1 40.0K 40.0K
/var/cache/fontconfig/e13b20fdb08344e0e6 4 9.0K 39.0K
/usr/lib/libdirect-1.2.so.0.7.0 3 13.0K 39.0K
/usr/lib/libXcursor.so.1.0.2 4 9.0K 38.0K
/usr/lib/scim-1.0/scim-helper-manager 1 36.0K 36.0K
/usr/lib/libXdmcp.so.6.0.0 7 5.0K 36.0K
/usr/lib/iceweasel/components/libbrowser 1 36.0K 36.0K
/lib/libgcc_s.so.1 6 6.0K 36.0K
/usr/lib/zsh/4.3.9/zsh/zutil.so 3 11.0K 35.0K
/usr/lib/zsh/4.3.9/zsh/parameter.so 3 11.0K 34.0K
/var/cache/fontconfig/945677eb7aeaf62f1d 4 8.0K 33.0K
/var/cache/fontconfig/6d41288fd70b0be22e 4 8.0K 33.0K
/usr/lib/zsh/4.3.9/zsh/complist.so 3 11.0K 33.0K
/usr/lib/libXau.so.6.0.0 7 4.0K 33.0K
/usr/share/fonts/truetype/ttf-bitstream- 2 16.0K 32.0K
/usr/lib/xulrunner-1.9/components/libmoz 1 32.0K 32.0K
/usr/lib/python2.5/lib-dynload/operator. 1 32.0K 32.0K
/usr/lib/libgconf2-4/2/libgconfbackend-x 1 32.0K 32.0K
/usr/lib/libdbus-1.so.3.4.0 1 32.0K 32.0K
/usr/lib/libXi.so.6.0.0 2 16.0K 32.0K
/usr/lib/libxcb-render.so.0.0.0 3 10.0K 31.0K
/usr/lib/libfusion-1.2.so.0.7.0 3 10.0K 31.0K
/usr/lib/libjpeg.so.62.0.0 3 10.0K 30.0K
/usr/lib/libXfixes.so.3.1.0 4 7.0K 30.0K
/lib/librt-2.9.so 3 9.0K 29.0K
/usr/share/mime/mime.cache 1 28.0K 28.0K
/usr/lib/xulrunner-1.9/xulrunner-stub 1 28.0K 28.0K
/usr/lib/xulrunner-1.9/components/libnkg 1 28.0K 28.0K
/usr/lib/scim-1.0/1.4.0/Config/simple.so 2 14.0K 28.0K
/usr/lib/libgnome-keyring.so.0.1.1 1 28.0K 28.0K
/usr/lib/libgconf2-4/gconfd-2 1 28.0K 28.0K
/usr/lib/gtk-2.0/2.10.0/immodules/im-xim 1 28.0K 28.0K
/lib/libpopt.so.0.0.0 1 28.0K 28.0K
/lib/libbz2.so.1.0.4 2 14.0K 28.0K
/lib/libattr.so.1.1.0 4 7.0K 28.0K
/usr/lib/libXrandr.so.2.2.0 3 9.0K 27.0K
/usr/lib/xulrunner-1.9/components/libdbu 1 24.0K 24.0K
/usr/lib/python2.5/lib-dynload/_struct.s 1 24.0K 24.0K
/usr/lib/perl/5.10.0/auto/List/Util/Util 1 24.0K 24.0K
/usr/lib/libstartup-notification-1.so.0. 1 24.0K 24.0K
/usr/lib/libart_lgpl_2.so.2.3.20 1 24.0K 24.0K
/usr/lib/libORBitCosNaming-2.so.0.1.0 1 24.0K 24.0K
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbu 2 12.0K 24.0K
/lib/libnss_dns-2.9.so 1 24.0K 24.0K
/usr/lib/libxcb-render-util.so.0.0.0 3 7.0K 23.0K
/usr/lib/libgmodule-2.0.so.0.2000.1 4 5.0K 22.0K
/usr/lib/zsh/4.3.9/zsh/rlimits.so 3 7.0K 21.0K
/usr/lib/libdbus-glib-1.so.2.1.0 1 21.0K 21.0K
/usr/lib/libSM.so.6.0.0 3 7.0K 21.0K
/lib/libcap.so.2.11 3 7.0K 21.0K
/usr/lib/python2.5/lib-dynload/time.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/strop.so 1 20.0K 20.0K
/usr/lib/python2.5/lib-dynload/_locale.s 1 20.0K 20.0K
/usr/lib/libgif.so.4.1.6 2 10.0K 20.0K
/usr/lib/libgailutil.so.18.0.1 1 20.0K 20.0K
/usr/lib/libfam.so.0.0.0 1 20.0K 20.0K
/usr/lib/libesd.so.0.2.36 1 20.0K 20.0K
/usr/lib/gconv/UTF-16.so 1 20.0K 20.0K
/usr/bin/dbus-launch 1 20.0K 20.0K
/usr/lib/libpcre.so.3.12.1 4 4.0K 19.0K
/usr/lib/libXinerama.so.1.0.0 3 6.0K 19.0K
/usr/lib/zsh/4.3.9/zsh/terminfo.so 3 6.0K 18.0K
/usr/lib/libgthread-2.0.so.0.2000.1 3 6.0K 18.0K
/lib/libutil-2.9.so 2 9.0K 18.0K
/usr/lib/gconv/gconv-modules.cache 6 2.0K 17.0K
/usr/share/fluxbox/nls/en_US.UTF-8/fluxb 1 16.0K 16.0K
/usr/lib/xulrunner-1.9/libxpcom.so 1 16.0K 16.0K
/usr/lib/scim-1.0/scim-launcher 1 16.0K 16.0K
/usr/lib/perl/5.10.0/auto/Fcntl/Fcntl.so 1 16.0K 16.0K
/usr/lib/pango/1.6.0/modules/pango-basic 2 8.0K 16.0K
/usr/lib/libtasn1.so.3.0.16 1 16.0K 16.0K
/usr/lib/libscim-x11utils-1.0.so.8.2.3 2 8.0K 16.0K
/usr/lib/libplc4.so.0d 1 16.0K 16.0K
/usr/lib/libavahi-client.so.3.2.4 1 16.0K 16.0K
/usr/lib/libXdamage.so.1.1.0 2 8.0K 16.0K
/usr/lib/libXcomposite.so.1.0.0 2 8.0K 16.0K
/usr/lib/imlib2/loaders/png.so 1 16.0K 16.0K
/usr/lib/imlib2/loaders/id3.so 1 16.0K 16.0K
/usr/lib/gconv/ISO8859-1.so 1 16.0K 16.0K
/usr/bin/xinit 1 16.0K 16.0K
/lib/libacl.so.1.1.0 1 16.0K 16.0K
/usr/lib/libavahi-common.so.3.5.0 1 14.0K 14.0K
/usr/lib/python2.5/lib-dynload/grp.so 1 12.0K 12.0K
/usr/lib/libplds4.so.0d 1 12.0K 12.0K
/usr/lib/libavahi-glib.so.1.0.1 1 12.0K 12.0K
/usr/lib/imlib2/loaders/xpm.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/tiff.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/tga.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/pnm.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/lbm.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/jpeg.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/gif.so 1 12.0K 12.0K
/usr/lib/imlib2/loaders/bmp.so 1 12.0K 12.0K
/lib/libnss_mdns4_minimal.so.2 1 12.0K 12.0K
/var/cache/fontconfig/de156ccd2eddbdc19d 4 2.0K 9.0K
/lib/libcrypt-2.9.so 1 9.0K 9.0K
/usr/lib/libgpg-error.so.0.3.0 1 8.0K 8.0K
/usr/lib/imlib2/loaders/zlib.so 1 8.0K 8.0K
/usr/lib/imlib2/loaders/bz2.so 1 8.0K 8.0K
/usr/lib/imlib2/loaders/argb.so 1 8.0K 8.0K
/var/cache/fontconfig/99e8ed0e538f840c56 4 1.0K 6.0K
/var/cache/fontconfig/089dead882dea3570f 4 1.0K 6.0K
/var/cache/fontconfig/0fafd173547752dce4 4 0 3.0K
[vsyscall] 15 0 0
[vdso] 15 0 0
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-20 2:31 ` Wu Fengguang
@ 2009-05-20 2:58 ` KOSAKI Motohiro
0 siblings, 0 replies; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-20 2:58 UTC (permalink / raw)
To: Wu Fengguang
Cc: kosaki.motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
> > > > I think smem can show which library evicted. Can you try it?
> > > >
> > > > download: http://www.selenic.com/smem/
> > > > usage: ./smem -m -r --abbreviate
> > >
> > > Sure, but I don't see much change in its output (see attachments).
> > >
> > > smem-console-0 is collected after fresh boot,
> > > smem-console-1 is collected after the big IO.
> >
> > hmmmm, your result has following characatistics.
> >
> > - no graphics component
> > - very few mapped library
> > (it is almost only zsh library)
> >
> > Can you try test on X environment?
>
> Sure, see the attached smem-x-0/1. This time we see sufficient differences.
thanks. hm, major shrinking item are
/usr/lib/xulrunner-1.9/libxul.so 11.0M => 2.1M
/usr/lib/libgtk-x11-2.0.so.0.1600.1 1.8M => 88.0K
/usr/lib/libperl.so.5.10.0 1.2M => 36.0K
IOW, inactive firefox's page were dropped.
I think that's sane. the latency of background window is not so important
on low memory desktop system.
user hope to use memory for foreground application.
Thus, droppint inactive application memory is sane behavior, I think.
>
> > > > We can't decide 9/10 is important or not. we need know actual evicted file list.
> > >
> > > Right. But what I measured is the activeness. Almost zero major page
> > > faults means the evicted 90% mapped pages are inactive during the
> > > long 300 seconds of IO.
> >
> > Agreed.
> > IOW, I don't think your test environment is typical desktop...
>
> Kind of :) It's fluxbox + terminal + firefox, a bare desktop for
> testing things out.
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 8:53 ` Wu Fengguang
2009-05-19 12:28 ` KOSAKI Motohiro
@ 2009-05-19 13:24 ` Rik van Riel
2009-05-19 15:55 ` KOSAKI Motohiro
1 sibling, 1 reply; 69+ messages in thread
From: Rik van Riel @ 2009-05-19 13:24 UTC (permalink / raw)
To: Wu Fengguang
Cc: KOSAKI Motohiro, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
Wu Fengguang wrote:
> Another (amazing) finding of the test is, only around 1/10 mapped pages
> are actively referenced in the absence of user activities.
>
> Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
I believe we already do, due to the active list not being
scanned if none of the streaming IO pages get promoted to
the active list.
--
All rights reversed.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 13:24 ` Rik van Riel
@ 2009-05-19 15:55 ` KOSAKI Motohiro
0 siblings, 0 replies; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 15:55 UTC (permalink / raw)
To: Rik van Riel
Cc: Wu Fengguang, Christoph Lameter, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Peter Zijlstra, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
>> Another (amazing) finding of the test is, only around 1/10 mapped pages
>> are actively referenced in the absence of user activities.
>>
>> Shall we protect the remaining 9/10 inactive ones? This is a question ;-)
>
> I believe we already do, due to the active list not being
> scanned if none of the streaming IO pages get promoted to
> the active list.
his workload is,
lseek(0)
read(110 * 4096)
lseek(100 * 4096)
read(110 * 4096)
lseek(200 * 4096)
read(110 * 4096)
....
IOW, 90% pages move into inactive list, 10% (overlapped readed) pages
move into active list.
he think it is file server simulation.
I don't know it is good simulation or not.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-16 9:00 ` [PATCH 2/3] vmscan: make mapped executable pages the first class citizen Wu Fengguang
2009-05-16 9:28 ` Wu Fengguang
@ 2009-05-19 6:39 ` Pekka Enberg
2009-05-19 6:56 ` KOSAKI Motohiro
` (2 more replies)
1 sibling, 3 replies; 69+ messages in thread
From: Pekka Enberg @ 2009-05-19 6:39 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Elladan, Nick Piggin, Johannes Weiner,
Christoph Lameter, KOSAKI Motohiro, Peter Zijlstra, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
Hi!
On Sat, May 16, 2009 at 12:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> @@ -1272,28 +1273,40 @@ static void shrink_active_list(unsigned
>
> /* page_referenced clears PageReferenced */
> if (page_mapping_inuse(page) &&
> - page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
> + page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
> pgmoved++;
> + /*
> + * Identify referenced, file-backed active pages and
> + * give them one more trip around the active list. So
> + * that executable code get better chances to stay in
> + * memory under moderate memory pressure. Anon pages
> + * are ignored, since JVM can create lots of anon
> + * VM_EXEC pages.
> + */
> + if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
> + list_add(&page->lru, &l_active);
> + continue;
> + }
Why do we need to skip JIT'd code? There are plenty of desktop
applications that use Mono, for example, and it would be nice if we
gave them the same treatment as native applications. Likewise, I am
sure all browsers that use JIT for JavaScript need to be considered.
Pekka
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 6:39 ` Pekka Enberg
@ 2009-05-19 6:56 ` KOSAKI Motohiro
2009-05-19 7:44 ` Peter Zijlstra
2009-05-19 13:14 ` Rik van Riel
2 siblings, 0 replies; 69+ messages in thread
From: KOSAKI Motohiro @ 2009-05-19 6:56 UTC (permalink / raw)
To: Pekka Enberg
Cc: kosaki.motohiro, Wu Fengguang, Andrew Morton, LKML, Elladan,
Nick Piggin, Johannes Weiner, Christoph Lameter, Peter Zijlstra,
Rik van Riel, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
Hi
> Hi!
>
> On Sat, May 16, 2009 at 12:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > @@ -1272,28 +1273,40 @@ static void shrink_active_list(unsigned
> >
> > /* page_referenced clears PageReferenced */
> > if (page_mapping_inuse(page) &&
> > - page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
> > + page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
> > pgmoved++;
> > + /*
> > + * Identify referenced, file-backed active pages and
> > + * give them one more trip around the active list. So
> > + * that executable code get better chances to stay in
> > + * memory under moderate memory pressure. Anon pages
> > + * are ignored, since JVM can create lots of anon
> > + * VM_EXEC pages.
> > + */
> > + if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
> > + list_add(&page->lru, &l_active);
> > + continue;
> > + }
>
> Why do we need to skip JIT'd code? There are plenty of desktop
> applications that use Mono, for example, and it would be nice if we
> gave them the same treatment as native applications. Likewise, I am
> sure all browsers that use JIT for JavaScript need to be considered.
anon pages are already protected from streaming-io by get_scan_ratio().
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 6:39 ` Pekka Enberg
2009-05-19 6:56 ` KOSAKI Motohiro
@ 2009-05-19 7:44 ` Peter Zijlstra
2009-05-19 8:05 ` Pekka Enberg
2009-05-19 13:14 ` Rik van Riel
2 siblings, 1 reply; 69+ messages in thread
From: Peter Zijlstra @ 2009-05-19 7:44 UTC (permalink / raw)
To: Pekka Enberg
Cc: Wu Fengguang, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Christoph Lameter, KOSAKI Motohiro, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, 2009-05-19 at 09:39 +0300, Pekka Enberg wrote:
> Hi!
>
> On Sat, May 16, 2009 at 12:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > @@ -1272,28 +1273,40 @@ static void shrink_active_list(unsigned
> >
> > /* page_referenced clears PageReferenced */
> > if (page_mapping_inuse(page) &&
> > - page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
> > + page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
> > pgmoved++;
> > + /*
> > + * Identify referenced, file-backed active pages and
> > + * give them one more trip around the active list. So
> > + * that executable code get better chances to stay in
> > + * memory under moderate memory pressure. Anon pages
> > + * are ignored, since JVM can create lots of anon
> > + * VM_EXEC pages.
> > + */
> > + if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
> > + list_add(&page->lru, &l_active);
> > + continue;
> > + }
>
> Why do we need to skip JIT'd code? There are plenty of desktop
> applications that use Mono, for example, and it would be nice if we
> gave them the same treatment as native applications. Likewise, I am
> sure all browsers that use JIT for JavaScript need to be considered.
Its a sekrit conspiracy against bloat by making JIT'd crap run
slower :-)
<rant>
Anyway, I just checked, we install tons of mono junk for _2_
applications, f-spot and tomboy, both are shite and both have
alternatives not requiring this disease.
</rant>
But seriously, like Kosaka-san already said, anonymous pages are treated
differently from file pages and should not suffer the same problems.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 7:44 ` Peter Zijlstra
@ 2009-05-19 8:05 ` Pekka Enberg
2009-05-19 8:12 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Pekka Enberg @ 2009-05-19 8:05 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Wu Fengguang, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Christoph Lameter, KOSAKI Motohiro, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
Hi Peter,
On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> Its a sekrit conspiracy against bloat by making JIT'd crap run
> slower :-)
>
> <rant>
> Anyway, I just checked, we install tons of mono junk for _2_
> applications, f-spot and tomboy, both are shite and both have
> alternatives not requiring this disease.
> </rant>
:-)
On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> But seriously, like Kosaka-san already said, anonymous pages are treated
> differently from file pages and should not suffer the same problems.
OK, thanks for the explanation. The comment is a little bit misleading
because I got the impression that we don't care about anon exec pages.
Pekka
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 8:05 ` Pekka Enberg
@ 2009-05-19 8:12 ` Wu Fengguang
2009-05-19 8:14 ` Pekka Enberg
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 8:12 UTC (permalink / raw)
To: Pekka Enberg
Cc: Peter Zijlstra, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Christoph Lameter, KOSAKI Motohiro, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, May 19, 2009 at 04:05:51PM +0800, Pekka Enberg wrote:
> Hi Peter,
>
> On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> > Its a sekrit conspiracy against bloat by making JIT'd crap run
> > slower :-)
> >
> > <rant>
> > Anyway, I just checked, we install tons of mono junk for _2_
> > applications, f-spot and tomboy, both are shite and both have
> > alternatives not requiring this disease.
> > </rant>
>
> :-)
>
> On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> > But seriously, like Kosaka-san already said, anonymous pages are treated
> > differently from file pages and should not suffer the same problems.
>
> OK, thanks for the explanation. The comment is a little bit misleading
> because I got the impression that we don't care about anon exec pages.
Ah yes! Will this one dismiss the possible mis-interception?
/*
* Identify referenced, file-backed active pages and
* give them one more trip around the active list. So
* that executable code get better chances to stay in
* memory under moderate memory pressure. Anon pages
modified ==> * are not likely to be evicted by use-once streaming
modified ==> * IO, plus JVM can create lots of anon VM_EXEC pages,
modified ==> * so we ignore them here.
*/
if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
list_add(&page->lru, &l_active);
continue;
}
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 8:12 ` Wu Fengguang
@ 2009-05-19 8:14 ` Pekka Enberg
0 siblings, 0 replies; 69+ messages in thread
From: Pekka Enberg @ 2009-05-19 8:14 UTC (permalink / raw)
To: Wu Fengguang
Cc: Peter Zijlstra, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Christoph Lameter, KOSAKI Motohiro, Rik van Riel,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
On Tue, 2009-05-19 at 16:12 +0800, Wu Fengguang wrote:
> On Tue, May 19, 2009 at 04:05:51PM +0800, Pekka Enberg wrote:
> > Hi Peter,
> >
> > On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> > > Its a sekrit conspiracy against bloat by making JIT'd crap run
> > > slower :-)
> > >
> > > <rant>
> > > Anyway, I just checked, we install tons of mono junk for _2_
> > > applications, f-spot and tomboy, both are shite and both have
> > > alternatives not requiring this disease.
> > > </rant>
> >
> > :-)
> >
> > On Tue, 2009-05-19 at 09:44 +0200, Peter Zijlstra wrote:
> > > But seriously, like Kosaka-san already said, anonymous pages are treated
> > > differently from file pages and should not suffer the same problems.
> >
> > OK, thanks for the explanation. The comment is a little bit misleading
> > because I got the impression that we don't care about anon exec pages.
>
> Ah yes! Will this one dismiss the possible mis-interception?
>
> /*
> * Identify referenced, file-backed active pages and
> * give them one more trip around the active list. So
> * that executable code get better chances to stay in
> * memory under moderate memory pressure. Anon pages
> modified ==> * are not likely to be evicted by use-once streaming
> modified ==> * IO, plus JVM can create lots of anon VM_EXEC pages,
> modified ==> * so we ignore them here.
> */
> if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
> list_add(&page->lru, &l_active);
> continue;
> }
Yes, it's better. Even I can understand it now :-).
Pekka
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-19 6:39 ` Pekka Enberg
2009-05-19 6:56 ` KOSAKI Motohiro
2009-05-19 7:44 ` Peter Zijlstra
@ 2009-05-19 13:14 ` Rik van Riel
2 siblings, 0 replies; 69+ messages in thread
From: Rik van Riel @ 2009-05-19 13:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Wu Fengguang, Andrew Morton, LKML, Elladan, Nick Piggin,
Johannes Weiner, Christoph Lameter, KOSAKI Motohiro,
Peter Zijlstra, tytso@mit.edu, linux-mm@kvack.org,
minchan.kim@gmail.com
Pekka Enberg wrote:
> Why do we need to skip JIT'd code? There are plenty of desktop
> applications that use Mono, for example, and it would be nice if we
> gave them the same treatment as native applications. Likewise, I am
> sure all browsers that use JIT for JavaScript need to be considered.
JIT'd code lives in anonymous pages, which are already
protected from streaming file IO because they live on
the anonymous LRUs.
--
All rights reversed.
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list()
2009-05-16 9:00 [PATCH 0/3] make mapped executable pages the first class citizen Wu Fengguang
2009-05-16 9:00 ` [PATCH 1/3] vmscan: report vm_flags in page_referenced() Wu Fengguang
2009-05-16 9:00 ` [PATCH 2/3] vmscan: make mapped executable pages the first class citizen Wu Fengguang
@ 2009-05-16 9:00 ` Wu Fengguang
2009-05-16 13:39 ` Johannes Weiner
` (2 more replies)
2009-05-16 14:56 ` [PATCH 0/3] make mapped executable pages the first class citizen Peter Zijlstra
3 siblings, 3 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-16 9:00 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Rik van Riel, Wu Fengguang, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, peterz@infradead.org,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de, minchan.kim@gmail.com
[-- Attachment #1: mm-vmscan-reduce-code.patch --]
[-- Type: text/plain, Size: 4799 bytes --]
The "move pages to active list" and "move pages to inactive list"
code blocks are mostly identical and can be served by a function.
Thanks to Andrew Morton for pointing this out.
Note that buffer_heads_over_limit check will also be carried out
for re-activated pages, which is slightly different from pre-2.6.28
kernels. Also, Rik's "vmscan: evict use-once pages first" patch
could totally stop scans of active list when memory pressure is low.
So the net effect could be, the number of buffer heads is now more
likely to grow large.
CC: Rik van Riel <riel@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/vmscan.c | 95 ++++++++++++++++++++++----------------------------
1 file changed, 42 insertions(+), 53 deletions(-)
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1225,6 +1225,43 @@ static inline void note_zone_scanning_pr
* But we had to alter page->flags anyway.
*/
+static void move_active_pages_to_lru(struct zone *zone,
+ struct list_head *list,
+ enum lru_list lru)
+{
+ unsigned long pgmoved = 0;
+ struct pagevec pvec;
+ struct page *page;
+
+ pagevec_init(&pvec, 1);
+
+ while (!list_empty(list)) {
+ page = lru_to_page(list);
+ prefetchw_prev_lru_page(page, list, flags);
+
+ VM_BUG_ON(PageLRU(page));
+ SetPageLRU(page);
+
+ VM_BUG_ON(!PageActive(page));
+ if (lru == LRU_INACTIVE_ANON || lru == LRU_INACTIVE_FILE)
+ ClearPageActive(page); /* we are de-activating */
+
+ list_move(&page->lru, &zone->lru[lru].list);
+ mem_cgroup_add_lru_list(page, lru);
+ pgmoved++;
+
+ if (!pagevec_add(&pvec, page) || list_empty(list)) {
+ spin_unlock_irq(&zone->lru_lock);
+ if (buffer_heads_over_limit)
+ pagevec_strip(&pvec);
+ __pagevec_release(&pvec);
+ spin_lock_irq(&zone->lru_lock);
+ }
+ }
+ __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+ if (lru == LRU_INACTIVE_ANON || lru == LRU_INACTIVE_FILE)
+ __count_vm_events(PGDEACTIVATE, pgmoved);
+}
static void shrink_active_list(unsigned long nr_pages, struct zone *zone,
struct scan_control *sc, int priority, int file)
@@ -1236,8 +1273,6 @@ static void shrink_active_list(unsigned
LIST_HEAD(l_active);
LIST_HEAD(l_inactive);
struct page *page;
- struct pagevec pvec;
- enum lru_list lru;
struct zone_reclaim_stat *reclaim_stat = get_reclaim_stat(zone, sc);
lru_add_drain();
@@ -1254,6 +1289,7 @@ static void shrink_active_list(unsigned
}
reclaim_stat->recent_scanned[!!file] += pgmoved;
+ __count_zone_vm_events(PGREFILL, zone, pgscanned);
if (file)
__mod_zone_page_state(zone, NR_ACTIVE_FILE, -pgmoved);
else
@@ -1295,8 +1331,6 @@ static void shrink_active_list(unsigned
/*
* Move pages back to the lru list.
*/
- pagevec_init(&pvec, 1);
-
spin_lock_irq(&zone->lru_lock);
/*
* Count referenced pages from currently used mappings as rotated.
@@ -1305,57 +1339,12 @@ static void shrink_active_list(unsigned
*/
reclaim_stat->recent_rotated[!!file] += pgmoved;
- pgmoved = 0; /* count pages moved to inactive list */
- lru = LRU_BASE + file * LRU_FILE;
- while (!list_empty(&l_inactive)) {
- page = lru_to_page(&l_inactive);
- prefetchw_prev_lru_page(page, &l_inactive, flags);
- VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
- VM_BUG_ON(!PageActive(page));
- ClearPageActive(page);
-
- list_move(&page->lru, &zone->lru[lru].list);
- mem_cgroup_add_lru_list(page, lru);
- pgmoved++;
- if (!pagevec_add(&pvec, page)) {
- spin_unlock_irq(&zone->lru_lock);
- if (buffer_heads_over_limit)
- pagevec_strip(&pvec);
- __pagevec_release(&pvec);
- spin_lock_irq(&zone->lru_lock);
- }
- }
- __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
- __count_zone_vm_events(PGREFILL, zone, pgscanned);
- __count_vm_events(PGDEACTIVATE, pgmoved);
-
- pgmoved = 0; /* count pages moved back to active list */
- lru = LRU_ACTIVE + file * LRU_FILE;
- while (!list_empty(&l_active)) {
- page = lru_to_page(&l_active);
- prefetchw_prev_lru_page(page, &l_active, flags);
- VM_BUG_ON(PageLRU(page));
- SetPageLRU(page);
- VM_BUG_ON(!PageActive(page));
-
- list_move(&page->lru, &zone->lru[lru].list);
- mem_cgroup_add_lru_list(page, lru);
- pgmoved++;
- if (!pagevec_add(&pvec, page)) {
- spin_unlock_irq(&zone->lru_lock);
- if (buffer_heads_over_limit)
- pagevec_strip(&pvec);
- __pagevec_release(&pvec);
- spin_lock_irq(&zone->lru_lock);
- }
- }
- __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+ move_active_pages_to_lru(zone, &l_active,
+ LRU_ACTIVE + file * LRU_FILE);
+ move_active_pages_to_lru(zone, &l_inactive,
+ LRU_BASE + file * LRU_FILE);
spin_unlock_irq(&zone->lru_lock);
- if (buffer_heads_over_limit)
- pagevec_strip(&pvec);
- pagevec_release(&pvec);
}
static int inactive_anon_is_low_global(struct zone *zone)
--
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list()
2009-05-16 9:00 ` [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list() Wu Fengguang
@ 2009-05-16 13:39 ` Johannes Weiner
2009-05-16 13:47 ` Wu Fengguang
2009-05-16 14:35 ` Rik van Riel
2009-05-17 1:24 ` Minchan Kim
2 siblings, 1 reply; 69+ messages in thread
From: Johannes Weiner @ 2009-05-16 13:39 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Rik van Riel, Christoph Lameter,
KOSAKI Motohiro, peterz@infradead.org, tytso@mit.edu,
linux-mm@kvack.org, elladan@eskimo.com, npiggin@suse.de,
minchan.kim@gmail.com
On Sat, May 16, 2009 at 05:00:08PM +0800, Wu Fengguang wrote:
> The "move pages to active list" and "move pages to inactive list"
> code blocks are mostly identical and can be served by a function.
>
> Thanks to Andrew Morton for pointing this out.
>
> Note that buffer_heads_over_limit check will also be carried out
> for re-activated pages, which is slightly different from pre-2.6.28
> kernels. Also, Rik's "vmscan: evict use-once pages first" patch
> could totally stop scans of active list when memory pressure is low.
> So the net effect could be, the number of buffer heads is now more
> likely to grow large.
I don't think that this could be harmful. We just preserve the buffer
mappings of what we consider the working set and with low memory
pressure, as you say, this set is not big.
As to stripping of reactivated pages: the only pages we re-activate
for now are those VM_EXEC mapped ones. Since we don't expect IO from
or to these pages, removing the buffer mappings in case they grow too
large should be okay, I guess.
> CC: Rik van Riel <riel@redhat.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list()
2009-05-16 13:39 ` Johannes Weiner
@ 2009-05-16 13:47 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-16 13:47 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, LKML, Rik van Riel, Christoph Lameter,
KOSAKI Motohiro, peterz@infradead.org, tytso@mit.edu,
linux-mm@kvack.org, elladan@eskimo.com, npiggin@suse.de,
minchan.kim@gmail.com
On Sat, May 16, 2009 at 09:39:50PM +0800, Johannes Weiner wrote:
> On Sat, May 16, 2009 at 05:00:08PM +0800, Wu Fengguang wrote:
> > The "move pages to active list" and "move pages to inactive list"
> > code blocks are mostly identical and can be served by a function.
> >
> > Thanks to Andrew Morton for pointing this out.
> >
> > Note that buffer_heads_over_limit check will also be carried out
> > for re-activated pages, which is slightly different from pre-2.6.28
> > kernels. Also, Rik's "vmscan: evict use-once pages first" patch
> > could totally stop scans of active list when memory pressure is low.
> > So the net effect could be, the number of buffer heads is now more
> > likely to grow large.
>
> I don't think that this could be harmful. We just preserve the buffer
> mappings of what we consider the working set and with low memory
> pressure, as you say, this set is not big.
>
> As to stripping of reactivated pages: the only pages we re-activate
> for now are those VM_EXEC mapped ones. Since we don't expect IO from
> or to these pages, removing the buffer mappings in case they grow too
> large should be okay, I guess.
Agreed - and good analyzes, thanks!
Fengguang
> > CC: Rik van Riel <riel@redhat.com>
> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
>
> Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list()
2009-05-16 9:00 ` [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list() Wu Fengguang
2009-05-16 13:39 ` Johannes Weiner
@ 2009-05-16 14:35 ` Rik van Riel
2009-05-17 1:24 ` Minchan Kim
2 siblings, 0 replies; 69+ messages in thread
From: Rik van Riel @ 2009-05-16 14:35 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Christoph Lameter, KOSAKI Motohiro,
hannes@cmpxchg.org, peterz@infradead.org, tytso@mit.edu,
linux-mm@kvack.org, elladan@eskimo.com, npiggin@suse.de,
minchan.kim@gmail.com
Wu Fengguang wrote:
> The "move pages to active list" and "move pages to inactive list"
> code blocks are mostly identical and can be served by a function.
>
> Thanks to Andrew Morton for pointing this out.
>
> Note that buffer_heads_over_limit check will also be carried out
> for re-activated pages, which is slightly different from pre-2.6.28
> kernels. Also, Rik's "vmscan: evict use-once pages first" patch
> could totally stop scans of active list when memory pressure is low.
> So the net effect could be, the number of buffer heads is now more
> likely to grow large.
>
> CC: Rik van Riel <riel@redhat.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
--
All rights reversed.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list()
2009-05-16 9:00 ` [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list() Wu Fengguang
2009-05-16 13:39 ` Johannes Weiner
2009-05-16 14:35 ` Rik van Riel
@ 2009-05-17 1:24 ` Minchan Kim
2 siblings, 0 replies; 69+ messages in thread
From: Minchan Kim @ 2009-05-17 1:24 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, LKML, Rik van Riel, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, peterz@infradead.org,
tytso@mit.edu, linux-mm@kvack.org, elladan@eskimo.com,
npiggin@suse.de
On Sat, May 16, 2009 at 6:00 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> The "move pages to active list" and "move pages to inactive list"
> code blocks are mostly identical and can be served by a function.
>
> Thanks to Andrew Morton for pointing this out.
>
> Note that buffer_heads_over_limit check will also be carried out
> for re-activated pages, which is slightly different from pre-2.6.28
> kernels. Also, Rik's "vmscan: evict use-once pages first" patch
> could totally stop scans of active list when memory pressure is low.
To clarify, active file list. otherwise is good to me.
Thanks for your great effort to enhance VM. :)
> CC: Rik van Riel <riel@redhat.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
--
Kinds regards,
Minchan Kim
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-05-16 9:00 [PATCH 0/3] make mapped executable pages the first class citizen Wu Fengguang
` (2 preceding siblings ...)
2009-05-16 9:00 ` [PATCH 3/3] vmscan: merge duplicate code in shrink_active_list() Wu Fengguang
@ 2009-05-16 14:56 ` Peter Zijlstra
2009-06-17 21:11 ` Jesse Barnes
3 siblings, 1 reply; 69+ messages in thread
From: Peter Zijlstra @ 2009-05-16 14:56 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Andrew Morton, LKML
On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> Andrew,
>
> This patchset makes mapped executable pages the first class citizen.
> This version has incorparated many valuable comments from people in
> the CC list, and runs OK on my desktop. Let's test it in your -mm?
Seems like a good set to me. Thanks for following this through Wu!
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-05-16 14:56 ` [PATCH 0/3] make mapped executable pages the first class citizen Peter Zijlstra
@ 2009-06-17 21:11 ` Jesse Barnes
2009-06-17 21:37 ` Jesse Barnes
2009-06-18 1:25 ` Wu Fengguang
0 siblings, 2 replies; 69+ messages in thread
From: Jesse Barnes @ 2009-06-17 21:11 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Wu Fengguang, Andrew Morton, LKML
On Sat, 16 May 2009 16:56:16 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> > Andrew,
> >
> > This patchset makes mapped executable pages the first class citizen.
> > This version has incorparated many valuable comments from people in
> > the CC list, and runs OK on my desktop. Let's test it in your -mm?
>
> Seems like a good set to me. Thanks for following this through Wu!
Now that this set has hit the mainline I just wanted to chime in and
say this makes a big difference. Under my current load (a parallel
kernel build and virtualbox session the old kernel would have been
totally unusable. With Linus's current bits, things are much better
(still a little sluggish with a big dd going on in the virtualbox, but
actually usable).
Thanks!
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-17 21:11 ` Jesse Barnes
@ 2009-06-17 21:37 ` Jesse Barnes
2009-06-18 1:25 ` Wu Fengguang
1 sibling, 0 replies; 69+ messages in thread
From: Jesse Barnes @ 2009-06-17 21:37 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Peter Zijlstra, Wu Fengguang, Andrew Morton, LKML
On Wed, 17 Jun 2009 14:11:35 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sat, 16 May 2009 16:56:16 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> > > Andrew,
> > >
> > > This patchset makes mapped executable pages the first class
> > > citizen. This version has incorparated many valuable comments
> > > from people in the CC list, and runs OK on my desktop. Let's test
> > > it in your -mm?
> >
> > Seems like a good set to me. Thanks for following this through Wu!
>
> Now that this set has hit the mainline I just wanted to chime in and
> say this makes a big difference. Under my current load (a parallel
> kernel build and virtualbox session the old kernel would have been
> totally unusable. With Linus's current bits, things are much better
> (still a little sluggish with a big dd going on in the virtualbox, but
> actually usable).
To really make things better though, I changed from CFQ to deadline on
the disk I'm using. I also changed swappiness to 40 and reduced my
max_sectors_kb (512 -> 64) though...
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-17 21:11 ` Jesse Barnes
2009-06-17 21:37 ` Jesse Barnes
@ 2009-06-18 1:25 ` Wu Fengguang
2009-06-18 16:33 ` Jesse Barnes
2009-06-19 9:00 ` Wu, Fengguang
1 sibling, 2 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-06-18 1:25 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Peter Zijlstra, Andrew Morton, LKML, Rik van Riel, linux-mm
On Thu, Jun 18, 2009 at 05:11:35AM +0800, Jesse Barnes wrote:
> On Sat, 16 May 2009 16:56:16 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> > > Andrew,
> > >
> > > This patchset makes mapped executable pages the first class citizen.
> > > This version has incorparated many valuable comments from people in
> > > the CC list, and runs OK on my desktop. Let's test it in your -mm?
> >
> > Seems like a good set to me. Thanks for following this through Wu!
>
> Now that this set has hit the mainline I just wanted to chime in and
> say this makes a big difference. Under my current load (a parallel
> kernel build and virtualbox session the old kernel would have been
> totally unusable. With Linus's current bits, things are much better
> (still a little sluggish with a big dd going on in the virtualbox, but
> actually usable).
>
> Thanks!
Jesse, thank you for the feedback :) And I'd like to credit Rik for
his patch on protecting active file LRU pages from being flushed by
streaming IO!
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-18 1:25 ` Wu Fengguang
@ 2009-06-18 16:33 ` Jesse Barnes
2009-06-19 9:00 ` Wu, Fengguang
1 sibling, 0 replies; 69+ messages in thread
From: Jesse Barnes @ 2009-06-18 16:33 UTC (permalink / raw)
To: Wu Fengguang; +Cc: Peter Zijlstra, Andrew Morton, LKML, Rik van Riel, linux-mm
On Thu, 18 Jun 2009 09:25:32 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Thu, Jun 18, 2009 at 05:11:35AM +0800, Jesse Barnes wrote:
> > On Sat, 16 May 2009 16:56:16 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> > > > Andrew,
> > > >
> > > > This patchset makes mapped executable pages the first class
> > > > citizen. This version has incorparated many valuable comments
> > > > from people in the CC list, and runs OK on my desktop. Let's
> > > > test it in your -mm?
> > >
> > > Seems like a good set to me. Thanks for following this through Wu!
> >
> > Now that this set has hit the mainline I just wanted to chime in and
> > say this makes a big difference. Under my current load (a parallel
> > kernel build and virtualbox session the old kernel would have been
> > totally unusable. With Linus's current bits, things are much better
> > (still a little sluggish with a big dd going on in the virtualbox,
> > but actually usable).
> >
> > Thanks!
>
> Jesse, thank you for the feedback :) And I'd like to credit Rik for
> his patch on protecting active file LRU pages from being flushed by
> streaming IO!
Unfortunately I came in this morning to an OOM'd machine. I do push it
pretty hard, but this is the first time I've seen an OOM. It happened
yesterday evening while I was away from the machine:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426677] apt-check invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426682] apt-check cpuset=/ mems_allowed=0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426686] Pid: 23105, comm: apt-check Tainted: G B W 2.6.30 #11
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426688] Call Trace:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426696] [<ffffffff810861fd>] ? cpuset_print_task_mems_allowed+0x8d/0xa0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426701] [<ffffffff810b984e>] oom_kill_process+0x17e/0x290
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426705] [<ffffffff810b9e0b>] ? select_bad_process+0x8b/0x110
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426708] [<ffffffff810b9ee0>] __out_of_memory+0x50/0xb0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426712] [<ffffffff810b9f9f>] out_of_memory+0x5f/0xc0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426715] [<ffffffff810bc5a3>] __alloc_pages_nodemask+0x623/0x640
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426719] [<ffffffff810bf8ea>] __do_page_cache_readahead+0xda/0x210
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426722] [<ffffffff810bfa3c>] ra_submit+0x1c/0x20
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426725] [<ffffffff810b886e>] filemap_fault+0x3ce/0x3e0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426729] [<ffffffff810ce3a3>] __do_fault+0x53/0x510
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426732] [<ffffffff810d27ea>] handle_mm_fault+0x1da/0x8c0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426737] [<ffffffff814b5724>] do_page_fault+0x1a4/0x310
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426740] [<ffffffff814b31d5>] page_fault+0x25/0x30
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426742] Mem-Info:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426744] DMA per-cpu:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426746] CPU 0: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426748] CPU 1: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426750] CPU 2: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426752] CPU 3: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426754] DMA32 per-cpu:
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426756] CPU 0: hi: 186, btch: 31 usd: 103
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426758] CPU 1: hi: 186, btch: 31 usd: 117
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426760] CPU 2: hi: 186, btch: 31 usd: 181
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426762] CPU 3: hi: 186, btch: 31 usd: 181
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766] Active_anon:290797 active_file:28 inactive_anon:97034
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61 unevictable:11322 dirty:0 writeback:0 unstable:0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341 slab:13776 mapped:5880 pagetables:6851 bounce:0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426772] DMA free:7776kB min:40kB low:48kB high:60kB active_anon:556kB inactive_anon:524kB active_file:16kB inactive_file:0kB unevictable:0kB present:15340kB pages_scanned:30 all_unreclaimable? no
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426775] lowmem_reserve[]: 0 1935 1935 1935
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426781] DMA32 free:5588kB min:5608kB low:7008kB high:8412kB active_anon:1162632kB inactive_anon:387612kB active_file:96kB inactive_file:256kB unevictable:45288kB present:1982128kB pages_scanned:980 all_unreclaimable? no
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426784] lowmem_reserve[]: 0 0 0 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426787] DMA: 64*4kB 77*8kB 45*16kB 18*32kB 4*64kB 2*128kB 2*256kB 3*512kB 1*1024kB 1*2048kB 0*4096kB = 7800kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426796] DMA32: 871*4kB 149*8kB 1*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 5588kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426804] 151250 total pagecache pages
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426806] 18973 pages in swap cache
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426808] Swap cache stats: add 610640, delete 591667, find 144356/181468
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426810] Free swap = 0kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426811] Total swap = 979956kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434828] 507136 pages RAM
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434831] 23325 pages reserved
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434832] 190892 pages shared
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434833] 248816 pages non-shared
As you can see, all my swap has been eaten and my anon lists are pretty
huge (relative to memory size, I only have 2G in this box). I suspect
the gfx driver is eating quite a bit of the anon memory, but this is
the first OOM I've seen... I'll look around for some tools to analyze
my anon memory usage; maybe Virtualbox is doing something pathological;
clearly something is out of control here at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-18 1:25 ` Wu Fengguang
2009-06-18 16:33 ` Jesse Barnes
@ 2009-06-19 9:00 ` Wu, Fengguang
2009-06-19 9:04 ` Peter Zijlstra
1 sibling, 1 reply; 69+ messages in thread
From: Wu, Fengguang @ 2009-06-19 9:00 UTC (permalink / raw)
To: Jesse Barnes
Cc: Peter Zijlstra, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com,
Jesse Barnes, Wang, Roger
[add CC]
This OOM case looks like the same bug encountered by David Howells.
> Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766] Active_anon:290797 active_file:28 inactive_anon:97034
> Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61 unevictable:11322 dirty:0 writeback:0 unstable:0
> Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341 slab:13776 mapped:5880 pagetables:6851 bounce:0
active/inactive_anon pages take up 4/5 memory. Are you using TMPFS a lot?
Thanks,
Fengguang
On Thu, 18 Jun 2009 09:25:32 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Thu, Jun 18, 2009 at 05:11:35AM +0800, Jesse Barnes wrote:
> > On Sat, 16 May 2009 16:56:16 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > > On Sat, 2009-05-16 at 17:00 +0800, Wu Fengguang wrote:
> > > > Andrew,
> > > >
> > > > This patchset makes mapped executable pages the first class
> > > > citizen. This version has incorparated many valuable comments
> > > > from people in the CC list, and runs OK on my desktop. Let's
> > > > test it in your -mm?
> > >
> > > Seems like a good set to me. Thanks for following this through Wu!
> >
> > Now that this set has hit the mainline I just wanted to chime in and
> > say this makes a big difference. Under my current load (a parallel
> > kernel build and virtualbox session the old kernel would have been
> > totally unusable. With Linus's current bits, things are much better
> > (still a little sluggish with a big dd going on in the virtualbox,
> > but actually usable).
> >
> > Thanks!
>
> Jesse, thank you for the feedback :) And I'd like to credit Rik for
> his patch on protecting active file LRU pages from being flushed by
> streaming IO!
Unfortunately I came in this morning to an OOM'd machine. I do push it
pretty hard, but this is the first time I've seen an OOM. It happened
yesterday evening while I was away from the machine:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426677] apt-check invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426682] apt-check cpuset=/ mems_allowed=0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426686] Pid: 23105, comm: apt-check Tainted: G B W 2.6.30 #11
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426688] Call Trace:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426696] [<ffffffff810861fd>] ? cpuset_print_task_mems_allowed+0x8d/0xa0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426701] [<ffffffff810b984e>] oom_kill_process+0x17e/0x290
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426705] [<ffffffff810b9e0b>] ? select_bad_process+0x8b/0x110
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426708] [<ffffffff810b9ee0>] __out_of_memory+0x50/0xb0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426712] [<ffffffff810b9f9f>] out_of_memory+0x5f/0xc0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426715] [<ffffffff810bc5a3>] __alloc_pages_nodemask+0x623/0x640
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426719] [<ffffffff810bf8ea>] __do_page_cache_readahead+0xda/0x210
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426722] [<ffffffff810bfa3c>] ra_submit+0x1c/0x20
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426725] [<ffffffff810b886e>] filemap_fault+0x3ce/0x3e0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426729] [<ffffffff810ce3a3>] __do_fault+0x53/0x510
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426732] [<ffffffff810d27ea>] handle_mm_fault+0x1da/0x8c0
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426737] [<ffffffff814b5724>] do_page_fault+0x1a4/0x310
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426740] [<ffffffff814b31d5>] page_fault+0x25/0x30
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426742] Mem-Info:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426744] DMA per-cpu:
Jun 18 07:44:52 jbarnes-g45 kernel: [64377.426746] CPU 0: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426748] CPU 1: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426750] CPU 2: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426752] CPU 3: hi: 0, btch: 1 usd: 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426754] DMA32 per-cpu:
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426756] CPU 0: hi: 186, btch: 31 usd: 103
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426758] CPU 1: hi: 186, btch: 31 usd: 117
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426760] CPU 2: hi: 186, btch: 31 usd: 181
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426762] CPU 3: hi: 186, btch: 31 usd: 181
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766] Active_anon:290797 active_file:28 inactive_anon:97034
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61 unevictable:11322 dirty:0 writeback:0 unstable:0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341 slab:13776 mapped:5880 pagetables:6851 bounce:0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426772] DMA free:7776kB min:40kB low:48kB high:60kB active_anon:556kB inactive_anon:524kB active_file:16kB inactive_file:0kB unevictable:0kB present:15340kB pages_scanned:30 all_unreclaimable? no
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426775] lowmem_reserve[]: 0 1935 1935 1935
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426781] DMA32 free:5588kB min:5608kB low:7008kB high:8412kB active_anon:1162632kB inactive_anon:387612kB active_file:96kB inactive_file:256kB unevictable:45288kB present:1982128kB pages_scanned:980 all_unreclaimable? no
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426784] lowmem_reserve[]: 0 0 0 0
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426787] DMA: 64*4kB 77*8kB 45*16kB 18*32kB 4*64kB 2*128kB 2*256kB 3*512kB 1*1024kB 1*2048kB 0*4096kB = 7800kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426796] DMA32: 871*4kB 149*8kB 1*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 5588kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426804] 151250 total pagecache pages
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426806] 18973 pages in swap cache
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426808] Swap cache stats: add 610640, delete 591667, find 144356/181468
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426810] Free swap = 0kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426811] Total swap = 979956kB
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434828] 507136 pages RAM
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434831] 23325 pages reserved
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434832] 190892 pages shared
Jun 18 07:44:53 jbarnes-g45 kernel: [64377.434833] 248816 pages non-shared
As you can see, all my swap has been eaten and my anon lists are pretty
huge (relative to memory size, I only have 2G in this box). I suspect
the gfx driver is eating quite a bit of the anon memory, but this is
the first OOM I've seen... I'll look around for some tools to analyze
my anon memory usage; maybe Virtualbox is doing something pathological;
clearly something is out of control here at any rate.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-19 9:00 ` Wu, Fengguang
@ 2009-06-19 9:04 ` Peter Zijlstra
2009-06-19 9:32 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Peter Zijlstra @ 2009-06-19 9:04 UTC (permalink / raw)
To: Wu, Fengguang
Cc: Jesse Barnes, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com,
Wang, Roger
On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> [add CC]
>
> This OOM case looks like the same bug encountered by David Howells.
>
> > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766] Active_anon:290797 active_file:28 inactive_anon:97034
> > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61 unevictable:11322 dirty:0 writeback:0 unstable:0
> > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341 slab:13776 mapped:5880 pagetables:6851 bounce:0
>
> active/inactive_anon pages take up 4/5 memory. Are you using TMPFS a lot?
I suspect its his GEM thingy ;-)
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-19 9:04 ` Peter Zijlstra
@ 2009-06-19 9:32 ` Wu Fengguang
2009-06-19 16:43 ` Jesse Barnes
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-06-19 9:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jesse Barnes, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com,
Wang, Roger
On Fri, Jun 19, 2009 at 05:04:49PM +0800, Peter Zijlstra wrote:
> On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> > [add CC]
> >
> > This OOM case looks like the same bug encountered by David Howells.
> >
> > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766] Active_anon:290797 active_file:28 inactive_anon:97034
> > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61 unevictable:11322 dirty:0 writeback:0 unstable:0
> > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341 slab:13776 mapped:5880 pagetables:6851 bounce:0
> >
> > active/inactive_anon pages take up 4/5 memory. Are you using TMPFS a lot?
>
> I suspect its his GEM thingy ;-)
Very likely - GEM allocates drm objects from the internal tmpfs,
and libdrm_intel seems to never free drm objects from its cache.
Thanks,
Fengguang
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-19 9:32 ` Wu Fengguang
@ 2009-06-19 16:43 ` Jesse Barnes
2009-07-04 1:27 ` Roger WANG
0 siblings, 1 reply; 69+ messages in thread
From: Jesse Barnes @ 2009-06-19 16:43 UTC (permalink / raw)
To: Wu Fengguang
Cc: Peter Zijlstra, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com,
Wang, Roger
On Fri, 19 Jun 2009 17:32:24 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Fri, Jun 19, 2009 at 05:04:49PM +0800, Peter Zijlstra wrote:
> > On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> > > [add CC]
> > >
> > > This OOM case looks like the same bug encountered by David
> > > Howells.
> > >
> > > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766]
> > > > Active_anon:290797 active_file:28 inactive_anon:97034 Jun 18
> > > > 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61
> > > > unevictable:11322 dirty:0 writeback:0 unstable:0 Jun 18
> > > > 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341
> > > > slab:13776 mapped:5880 pagetables:6851 bounce:0
> > >
> > > active/inactive_anon pages take up 4/5 memory. Are you using
> > > TMPFS a lot?
> >
> > I suspect its his GEM thingy ;-)
>
> Very likely - GEM allocates drm objects from the internal tmpfs,
> and libdrm_intel seems to never free drm objects from its cache.
Yeah, a good chunk of that is GEM objects. I generally haven't seen
OOMs due to excessive GEM allocation though, until recently. We've got
some patches queued up to manage the object cache better (actually free
pages when we don't need them!), so that should help.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-06-19 16:43 ` Jesse Barnes
@ 2009-07-04 1:27 ` Roger WANG
2009-07-06 17:38 ` Jesse Barnes
0 siblings, 1 reply; 69+ messages in thread
From: Roger WANG @ 2009-07-04 1:27 UTC (permalink / raw)
To: Jesse Barnes
Cc: Wu, Fengguang, Peter Zijlstra, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com
Hello Jesse,
On Sat, 2009-06-20 at 00:43 +0800 Jesse Barnes wrote:
> On Fri, 19 Jun 2009 17:32:24 +0800
> Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> > On Fri, Jun 19, 2009 at 05:04:49PM +0800, Peter Zijlstra wrote:
> > > On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> > > > [add CC]
> > > >
> > > > This OOM case looks like the same bug encountered by David
> > > > Howells.
> > > >
> > > > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766]
> > > > > Active_anon:290797 active_file:28 inactive_anon:97034 Jun 18
> > > > > 07:44:53 jbarnes-g45 kernel: [64377.426767] inactive_file:61
> > > > > unevictable:11322 dirty:0 writeback:0 unstable:0 Jun 18
> > > > > 07:44:53 jbarnes-g45 kernel: [64377.426768] free:3341
> > > > > slab:13776 mapped:5880 pagetables:6851 bounce:0
> > > >
> > > > active/inactive_anon pages take up 4/5 memory. Are you using
> > > > TMPFS a lot?
> > >
> > > I suspect its his GEM thingy ;-)
> >
> > Very likely - GEM allocates drm objects from the internal tmpfs,
> > and libdrm_intel seems to never free drm objects from its cache.
>
> Yeah, a good chunk of that is GEM objects. I generally haven't seen
> OOMs due to excessive GEM allocation though, until recently. We've got
> some patches queued up to manage the object cache better (actually free
> pages when we don't need them!), so that should help.
Could you please point me to those patches so I can try them here? I
have to kill my X once per day.
Thanks
--Roger
>
> --
> Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH 0/3] make mapped executable pages the first class citizen
2009-07-04 1:27 ` Roger WANG
@ 2009-07-06 17:38 ` Jesse Barnes
0 siblings, 0 replies; 69+ messages in thread
From: Jesse Barnes @ 2009-07-06 17:38 UTC (permalink / raw)
To: Roger WANG
Cc: Wu, Fengguang, Peter Zijlstra, Andrew Morton, LKML, Rik van Riel,
linux-mm@kvack.org, Mel Gorman, Christoph Lameter,
KOSAKI Motohiro, hannes@cmpxchg.org, tytso@mit.edu,
elladan@eskimo.com, npiggin@suse.de, minchan.kim@gmail.com
On Sat, 4 Jul 2009 09:27:54 +0800
Roger WANG <roger.wang@intel.com> wrote:
> Hello Jesse,
>
> On Sat, 2009-06-20 at 00:43 +0800 Jesse Barnes wrote:
> > On Fri, 19 Jun 2009 17:32:24 +0800
> > Wu Fengguang <fengguang.wu@intel.com> wrote:
> >
> > > On Fri, Jun 19, 2009 at 05:04:49PM +0800, Peter Zijlstra wrote:
> > > > On Fri, 2009-06-19 at 17:00 +0800, Wu, Fengguang wrote:
> > > > > [add CC]
> > > > >
> > > > > This OOM case looks like the same bug encountered by David
> > > > > Howells.
> > > > >
> > > > > > Jun 18 07:44:53 jbarnes-g45 kernel: [64377.426766]
> > > > > > Active_anon:290797 active_file:28 inactive_anon:97034 Jun 18
> > > > > > 07:44:53 jbarnes-g45 kernel: [64377.426767]
> > > > > > inactive_file:61 unevictable:11322 dirty:0 writeback:0
> > > > > > unstable:0 Jun 18 07:44:53 jbarnes-g45 kernel:
> > > > > > [64377.426768] free:3341 slab:13776 mapped:5880
> > > > > > pagetables:6851 bounce:0
> > > > >
> > > > > active/inactive_anon pages take up 4/5 memory. Are you using
> > > > > TMPFS a lot?
> > > >
> > > > I suspect its his GEM thingy ;-)
> > >
> > > Very likely - GEM allocates drm objects from the internal tmpfs,
> > > and libdrm_intel seems to never free drm objects from its cache.
> >
> > Yeah, a good chunk of that is GEM objects. I generally haven't seen
> > OOMs due to excessive GEM allocation though, until recently. We've
> > got some patches queued up to manage the object cache better
> > (actually free pages when we don't need them!), so that should help.
>
> Could you please point me to those patches so I can try them here? I
> have to kill my X once per day.
They're all upstream now; I've been running 2.6.31ish plus the latest
libdrm, Mesa and xf86-video-intel for a week or so and things are much
better (using the Ubuntu xorg edgers repo).
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-17 2:23 Wu Fengguang
@ 2009-05-17 2:23 ` Wu Fengguang
2009-05-19 8:59 ` Wu Fengguang
0 siblings, 1 reply; 69+ messages in thread
From: Wu Fengguang @ 2009-05-17 2:23 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Elladan, Nick Piggin, Christoph Lameter, KOSAKI Motohiro,
Rik van Riel, Peter Zijlstra, Wu Fengguang, hannes@cmpxchg.org,
tytso@mit.edu, linux-mm@kvack.org, minchan.kim@gmail.com
[-- Attachment #1: mm-vmscan-protect-exec-referenced.patch --]
[-- Type: text/plain, Size: 7607 bytes --]
Protect referenced PROT_EXEC mapped pages from being deactivated.
PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
currently running executables and their linked libraries, they shall really be
cached aggressively to provide good user experiences.
Thanks to Johannes Weiner for the advice to reuse the VMA walk in
page_referenced() to get the PROT_EXEC bit.
[more details]
( The consequences of this patch will have to be discussed together with
Rik van Riel's recent patch "vmscan: evict use-once pages first". )
( Some of the good points and insights are taken into this changelog.
Thanks to all the involved people for the great LKML discussions. )
the problem
-----------
For a typical desktop, the most precious working set is composed of
*actively accessed*
(1) memory mapped executables
(2) and their anonymous pages
(3) and other files
(4) and the dcache/icache/.. slabs
while the least important data are
(5) infrequently used or use-once files
For a typical desktop, one major problem is busty and large amount of (5)
use-once files flushing out the working set.
Inside the working set, (4) dcache/icache have already been too sticky ;-)
So we only have to care (2) anonymous and (1)(3) file pages.
anonymous pages
---------------
Anonymous pages are effectively immune to the streaming IO attack, because we
now have separate file/anon LRU lists. When the use-once files crowd into the
file LRU, the list's "quality" is significantly lowered. Therefore the scan
balance policy in get_scan_ratio() will choose to scan the (low quality) file
LRU much more frequently than the anon LRU.
file pages
----------
Rik proposed to *not* scan the active file LRU when the inactive list grows
larger than active list. This guarantees that when there are use-once streaming
IO, and the working set is not too large(so that active_size < inactive_size),
the active file LRU will *not* be scanned at all. So the not-too-large working
set can be well protected.
But there are also situations where the file working set is a bit large so that
(active_size >= inactive_size), or the streaming IOs are not purely use-once.
In these cases, the active list will be scanned slowly. Because the current
shrink_active_list() policy is to deactivate active pages regardless of their
referenced bits. The deactivated pages become susceptible to the streaming IO
attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
the deactivated pages don't have enough time to get re-referenced. Because a
user tend to switch between windows in intervals from seconds to minutes.
This patch holds mapped executable pages in the active list as long as they
are referenced during each full scan of the active list. Because the active
list is normally scanned much slower, they get longer grace time (eg. 100s)
for further references, which better matches the pace of user operations.
Therefore this patch greatly prolongs the in-cache time of executable code,
when there are moderate memory pressures.
before patch: guaranteed to be cached if reference intervals < I
after patch: guaranteed to be cached if reference intervals < I+A
(except when randomly reclaimed by the lumpy reclaim)
where
A = time to fully scan the active file LRU
I = time to fully scan the inactive file LRU
Note that normally A >> I.
side effects
------------
This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
but in a much smaller and well targeted scope.
One may worry about some one to abuse the PROT_EXEC heuristic. But as
Andrew Morton stated, there are other tricks to getting that sort of boost.
Another concern is the PROT_EXEC mapped pages growing large in rare cases,
and therefore hurting reclaim efficiency. But a sane application targeted for
large audience will never use PROT_EXEC for data mappings. If some home made
application tries to abuse that bit, it shall be aware of the consequences.
If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
CC: Elladan <elladan@eskimo.com>
CC: Nick Piggin <npiggin@suse.de>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/vmscan.c | 51 +++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 44 insertions(+), 7 deletions(-)
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1233,6 +1233,7 @@ static void shrink_active_list(unsigned
unsigned long pgscanned;
unsigned long vm_flags;
LIST_HEAD(l_hold); /* The pages which were snipped off */
+ LIST_HEAD(l_active);
LIST_HEAD(l_inactive);
struct page *page;
struct pagevec pvec;
@@ -1272,28 +1273,41 @@ static void shrink_active_list(unsigned
/* page_referenced clears PageReferenced */
if (page_mapping_inuse(page) &&
- page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
+ page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
pgmoved++;
+ /*
+ * Identify referenced, file-backed active pages and
+ * give them one more trip around the active list. So
+ * that executable code get better chances to stay in
+ * memory under moderate memory pressure. Anon pages
+ * are ignored, since JVM can create lots of anon
+ * VM_EXEC pages.
+ */
+ if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
+ list_add(&page->lru, &l_active);
+ continue;
+ }
+ }
list_add(&page->lru, &l_inactive);
}
/*
- * Move the pages to the [file or anon] inactive list.
+ * Move pages back to the lru list.
*/
pagevec_init(&pvec, 1);
- lru = LRU_BASE + file * LRU_FILE;
spin_lock_irq(&zone->lru_lock);
/*
- * Count referenced pages from currently used mappings as
- * rotated, even though they are moved to the inactive list.
- * This helps balance scan pressure between file and anonymous
- * pages in get_scan_ratio.
+ * Count referenced pages from currently used mappings as rotated,
+ * even though only some of them are actually re-activated. This
+ * helps balance scan pressure between file and anonymous pages in
+ * get_scan_ratio.
*/
reclaim_stat->recent_rotated[!!file] += pgmoved;
pgmoved = 0; /* count pages moved to inactive list */
+ lru = LRU_BASE + file * LRU_FILE;
while (!list_empty(&l_inactive)) {
page = lru_to_page(&l_inactive);
prefetchw_prev_lru_page(page, &l_inactive, flags);
@@ -1316,6 +1330,29 @@ static void shrink_active_list(unsigned
__mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
__count_zone_vm_events(PGREFILL, zone, pgscanned);
__count_vm_events(PGDEACTIVATE, pgmoved);
+
+ pgmoved = 0; /* count pages moved back to active list */
+ lru = LRU_ACTIVE + file * LRU_FILE;
+ while (!list_empty(&l_active)) {
+ page = lru_to_page(&l_active);
+ prefetchw_prev_lru_page(page, &l_active, flags);
+ VM_BUG_ON(PageLRU(page));
+ SetPageLRU(page);
+ VM_BUG_ON(!PageActive(page));
+
+ list_move(&page->lru, &zone->lru[lru].list);
+ mem_cgroup_add_lru_list(page, lru);
+ pgmoved++;
+ if (!pagevec_add(&pvec, page)) {
+ spin_unlock_irq(&zone->lru_lock);
+ if (buffer_heads_over_limit)
+ pagevec_strip(&pvec);
+ __pagevec_release(&pvec);
+ spin_lock_irq(&zone->lru_lock);
+ }
+ }
+ __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+
spin_unlock_irq(&zone->lru_lock);
if (buffer_heads_over_limit)
pagevec_strip(&pvec);
--
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH 2/3] vmscan: make mapped executable pages the first class citizen
2009-05-17 2:23 ` [PATCH 2/3] vmscan: " Wu Fengguang
@ 2009-05-19 8:59 ` Wu Fengguang
0 siblings, 0 replies; 69+ messages in thread
From: Wu Fengguang @ 2009-05-19 8:59 UTC (permalink / raw)
To: Andrew Morton
Cc: LKML, Elladan, Nick Piggin, Christoph Lameter, KOSAKI Motohiro,
Rik van Riel, Peter Zijlstra, hannes@cmpxchg.org, tytso@mit.edu,
linux-mm@kvack.org, minchan.kim@gmail.com
[update the comment that confused Pekka]
---
vmscan: make mapped executable pages the first class citizen
Protect referenced PROT_EXEC mapped pages from being deactivated.
PROT_EXEC(or its internal presentation VM_EXEC) pages normally belong to some
currently running executables and their linked libraries, they shall really be
cached aggressively to provide good user experiences.
Thanks to Johannes Weiner for the advice to reuse the VMA walk in
page_referenced() to get the PROT_EXEC bit.
[more details]
( The consequences of this patch will have to be discussed together with
Rik van Riel's recent patch "vmscan: evict use-once pages first". )
( Some of the good points and insights are taken into this changelog.
Thanks to all the involved people for the great LKML discussions. )
the problem
-----------
For a typical desktop, the most precious working set is composed of
*actively accessed*
(1) memory mapped executables
(2) and their anonymous pages
(3) and other files
(4) and the dcache/icache/.. slabs
while the least important data are
(5) infrequently used or use-once files
For a typical desktop, one major problem is busty and large amount of (5)
use-once files flushing out the working set.
Inside the working set, (4) dcache/icache have already been too sticky ;-)
So we only have to care (2) anonymous and (1)(3) file pages.
anonymous pages
---------------
Anonymous pages are effectively immune to the streaming IO attack, because we
now have separate file/anon LRU lists. When the use-once files crowd into the
file LRU, the list's "quality" is significantly lowered. Therefore the scan
balance policy in get_scan_ratio() will choose to scan the (low quality) file
LRU much more frequently than the anon LRU.
file pages
----------
Rik proposed to *not* scan the active file LRU when the inactive list grows
larger than active list. This guarantees that when there are use-once streaming
IO, and the working set is not too large(so that active_size < inactive_size),
the active file LRU will *not* be scanned at all. So the not-too-large working
set can be well protected.
But there are also situations where the file working set is a bit large so that
(active_size >= inactive_size), or the streaming IOs are not purely use-once.
In these cases, the active list will be scanned slowly. Because the current
shrink_active_list() policy is to deactivate active pages regardless of their
referenced bits. The deactivated pages become susceptible to the streaming IO
attack: the inactive list could be scanned fast (500MB / 50MBps = 10s) so that
the deactivated pages don't have enough time to get re-referenced. Because a
user tend to switch between windows in intervals from seconds to minutes.
This patch holds mapped executable pages in the active list as long as they
are referenced during each full scan of the active list. Because the active
list is normally scanned much slower, they get longer grace time (eg. 100s)
for further references, which better matches the pace of user operations.
Therefore this patch greatly prolongs the in-cache time of executable code,
when there are moderate memory pressures.
before patch: guaranteed to be cached if reference intervals < I
after patch: guaranteed to be cached if reference intervals < I+A
(except when randomly reclaimed by the lumpy reclaim)
where
A = time to fully scan the active file LRU
I = time to fully scan the inactive file LRU
Note that normally A >> I.
side effects
------------
This patch is safe in general, it restores the pre-2.6.28 mmap() behavior
but in a much smaller and well targeted scope.
One may worry about some one to abuse the PROT_EXEC heuristic. But as
Andrew Morton stated, there are other tricks to getting that sort of boost.
Another concern is the PROT_EXEC mapped pages growing large in rare cases,
and therefore hurting reclaim efficiency. But a sane application targeted for
large audience will never use PROT_EXEC for data mappings. If some home made
application tries to abuse that bit, it shall be aware of the consequences.
If it is abused to scale of 2/3 total memory, it gains nothing but overheads.
CC: Elladan <elladan@eskimo.com>
CC: Nick Piggin <npiggin@suse.de>
CC: Pekka Enberg <penberg@cs.helsinki.fi>
CC: Christoph Lameter <cl@linux-foundation.org>
CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
mm/vmscan.c | 52 +++++++++++++++++++++++++++++++++++++++++++-------
1 file changed, 45 insertions(+), 7 deletions(-)
--- linux.orig/mm/vmscan.c
+++ linux/mm/vmscan.c
@@ -1233,6 +1233,7 @@ static void shrink_active_list(unsigned
unsigned long pgscanned;
unsigned long vm_flags;
LIST_HEAD(l_hold); /* The pages which were snipped off */
+ LIST_HEAD(l_active);
LIST_HEAD(l_inactive);
struct page *page;
struct pagevec pvec;
@@ -1272,28 +1273,42 @@ static void shrink_active_list(unsigned
/* page_referenced clears PageReferenced */
if (page_mapping_inuse(page) &&
- page_referenced(page, 0, sc->mem_cgroup, &vm_flags))
+ page_referenced(page, 0, sc->mem_cgroup, &vm_flags)) {
pgmoved++;
+ /*
+ * Identify referenced, file-backed active pages and
+ * give them one more trip around the active list. So
+ * that executable code get better chances to stay in
+ * memory under moderate memory pressure. Anon pages
+ * are not likely to be evicted by use-once streaming
+ * IO, plus JVM can create lots of anon VM_EXEC pages,
+ * so we ignore them here.
+ */
+ if ((vm_flags & VM_EXEC) && !PageAnon(page)) {
+ list_add(&page->lru, &l_active);
+ continue;
+ }
+ }
list_add(&page->lru, &l_inactive);
}
/*
- * Move the pages to the [file or anon] inactive list.
+ * Move pages back to the lru list.
*/
pagevec_init(&pvec, 1);
- lru = LRU_BASE + file * LRU_FILE;
spin_lock_irq(&zone->lru_lock);
/*
- * Count referenced pages from currently used mappings as
- * rotated, even though they are moved to the inactive list.
- * This helps balance scan pressure between file and anonymous
- * pages in get_scan_ratio.
+ * Count referenced pages from currently used mappings as rotated,
+ * even though only some of them are actually re-activated. This
+ * helps balance scan pressure between file and anonymous pages in
+ * get_scan_ratio.
*/
reclaim_stat->recent_rotated[!!file] += pgmoved;
pgmoved = 0; /* count pages moved to inactive list */
+ lru = LRU_BASE + file * LRU_FILE;
while (!list_empty(&l_inactive)) {
page = lru_to_page(&l_inactive);
prefetchw_prev_lru_page(page, &l_inactive, flags);
@@ -1316,6 +1331,29 @@ static void shrink_active_list(unsigned
__mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
__count_zone_vm_events(PGREFILL, zone, pgscanned);
__count_vm_events(PGDEACTIVATE, pgmoved);
+
+ pgmoved = 0; /* count pages moved back to active list */
+ lru = LRU_ACTIVE + file * LRU_FILE;
+ while (!list_empty(&l_active)) {
+ page = lru_to_page(&l_active);
+ prefetchw_prev_lru_page(page, &l_active, flags);
+ VM_BUG_ON(PageLRU(page));
+ SetPageLRU(page);
+ VM_BUG_ON(!PageActive(page));
+
+ list_move(&page->lru, &zone->lru[lru].list);
+ mem_cgroup_add_lru_list(page, lru);
+ pgmoved++;
+ if (!pagevec_add(&pvec, page)) {
+ spin_unlock_irq(&zone->lru_lock);
+ if (buffer_heads_over_limit)
+ pagevec_strip(&pvec);
+ __pagevec_release(&pvec);
+ spin_lock_irq(&zone->lru_lock);
+ }
+ }
+ __mod_zone_page_state(zone, NR_LRU_BASE + lru, pgmoved);
+
spin_unlock_irq(&zone->lru_lock);
if (buffer_heads_over_limit)
pagevec_strip(&pvec);
^ permalink raw reply [flat|nested] 69+ messages in thread