All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Rik van Riel <riel@redhat.com>
Cc: balbir@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH -mm 00/16] VM pageout scalability improvements (V8)
Date: Tue, 27 May 2008 11:54:02 -0400	[thread overview]
Message-ID: <1211903642.7283.16.camel@lts-notebook> (raw)
In-Reply-To: <20080526153318.29edc0b2@bree.surriel.com>

On Mon, 2008-05-26 at 15:33 -0400, Rik van Riel wrote:
> On Mon, 26 May 2008 23:54:55 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > Rik van Riel wrote:
> > > On large memory systems, the VM can spend way too much time scanning
> > > through pages that it cannot (or should not) evict from memory. Not
> > > only does it use up CPU time, but it also provokes lock contention
> > > and can leave large systems under memory presure in a catatonic state.
> > 
> > Hi, Rik,
> > 
> > This patchset looks good (I did a brief scan). I'll go ahead and play with it?
> > What is a good memory size to test the patches on (to see improvements).
> 
> The larger, the better.  One known problem with the current upstream
> VM is large numbers of anonymous pages, or a mix of mlocked and anon
> pages.
> 
> Once the system needs to swap something out, every single anon page
> will have the referenced bit set and the system needs to do lots of
> scanning before it can evict the first page.  This scanning causes
> multiple CPUs to pile up and things slow down exponentially and/or
> catastrophically :)
> 
> Unfortunately the largest system I have access to on a regular basis
> has "only" 16GB of RAM :(
> 
> I am also making 2.6.25 based kernel RPMs available with the split LRU
> patch set, at http://people.redhat.com/riel/splitvm/
> 
> The most recently posted patches are newer, though...
> 

I tested Rik's previous patch set with my noreclaim/mlock patches over
the long weekend on 32GB systems--one ia64 [16cpu x 4 nodes] and one
x86_64 [8 core x 4 nodes] on 26-rc2-mm1.  A fairly heavy stress load ran
for 92-93 hours on each system w/o error.  Stats tracked throughout, no
leaked pages, ...  

Since Balbir is starting to look at this, I need to ask about
interaction with the memory controller.  It is currently unaware of the
noreclaim list.  I'm not sure what will happen if/when the memory
controller tries to reclaim a page that system has moved to the
noreclaim list.  Something we'll need to address.  It's on my list, but
I won't get to it for a couple of weeks.

Lee 


  reply	other threads:[~2008-05-27 15:54 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 19:55 [PATCH -mm 00/16] VM pageout scalability improvements (V8) Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 01/16] move isolate_lru_page() to vmscan.c Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 02/16] Use an indexed array for LRU variables Rik van Riel
2008-05-27 16:54   ` Lee Schermerhorn
2008-05-27 17:03     ` Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 03/16] use an array for the LRU pagevecs Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 04/16] free swap space on swap-in/activation Rik van Riel
2008-05-28  9:08   ` Daisuke Nishimura
2008-05-23 19:55 ` [PATCH -mm 05/16] define page_file_cache() function Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 06/16] split LRU lists into anon & file sets Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 07/16] second chance replacement for anonymous pages Rik van Riel
2008-05-28  5:36   ` Daisuke Nishimura
2008-05-28 13:39     ` Rik van Riel
2008-05-28 15:42       ` Daisuke Nishimura
2008-05-28 16:08         ` Rik van Riel
2008-05-28 11:03   ` KOSAKI Motohiro
2008-05-28 13:43     ` Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 08/16] add some sanity checks to get_scan_ratio Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 09/16] fix pagecache reclaim referenced bit check Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 10/16] add newly swapped in pages to the inactive list Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 11/16] more aggressively use lumpy reclaim Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 12/16] pageflag helpers for configed-out flags Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 13/16] No Reclaim LRU Infrastructure Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 14/16] Non-reclaimable page statistics Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 15/16] ramfs pages are non-reclaimable Rik van Riel
2008-05-23 19:55 ` [PATCH -mm 16/16] SHM_LOCKED pages are nonreclaimable Rik van Riel
2008-05-26 18:24 ` [PATCH -mm 00/16] VM pageout scalability improvements (V8) Balbir Singh
2008-05-26 19:33   ` Rik van Riel
2008-05-27 15:54     ` Lee Schermerhorn [this message]
2008-05-27 16:10       ` Balbir Singh
2008-05-28  1:12       ` KAMEZAWA Hiroyuki
2008-05-28 11:04         ` [RFC PATCH] No Reclaim LRU Infrastructure enhancement for memcgroup KOSAKI Motohiro
2008-05-29  2:30           ` Balbir Singh
2008-05-29 11:14             ` Daisuke Nishimura
2008-05-28 11:49     ` [PATCH -mm 00/16] VM pageout scalability improvements (V8) Balbir Singh
2008-05-28 13:33       ` KOSAKI Motohiro
2008-05-28 13:36         ` Balbir Singh
2008-05-29 12:47 ` Carsten Otte
2008-05-29 14:43   ` Rik van Riel

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=1211903642.7283.16.camel@lts-notebook \
    --to=lee.schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

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

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