linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Martin Hicks <mort@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Ray Bryant <raybry@engr.sgi.com>,
	mort@sgi.com, linux-mm@kvack.org, ak@suse.de
Subject: Re: [PATCH/RFC 0/4] VM: Manual and Automatic page cache reclaim
Date: Tue, 3 May 2005 09:21:02 -0400	[thread overview]
Message-ID: <20050503132102.GS19244@localhost> (raw)
In-Reply-To: <20050503010846.508bbe62.akpm@osdl.org>

On Tue, May 03, 2005 at 01:08:46AM -0700, Andrew Morton wrote:
> Ray Bryant <raybry@engr.sgi.com> wrote:
> >
> > ...
> > One of the common responses to changes in the VM system for optimizations
> > of this type is that we instead should devote our efforts to improving
> > the VM system algorithms and that we are taking an "easy way out" by
> > putting a hack into the VM system.
> 
> There's that plus the question which forever lurks around funky SGI patches:
> 
> 	How many machines in the world want this feature?
> 
> Because if the answer is "twelve" then gee it becomes hard to justify
> merging things into the mainline kernel.  Particularly when they add
> complexity to page reclaim.

And vendors seem hesitant because it isn't upstream.... chicken?  egg?

> 
> >  Fundamentally, the VM system cannot
> > predict the future behavior of the application in order to correctly
> > make this tradeoff.
> 
> Yup.  But we could add a knob to each zone which says, during page
> allocation "be more reluctant to advance onto the next node - do some
> direct reclaim instead"
> 
> And the good thing about that is that it is an easier merge because it's a
> simpler patch and because it's useful to more machines.  People can tune it
> and get better (or worse) performance from existing apps on NUMA.

The problem is that it really can't be a machine-wide policy.  This is
something that, at the very least, has to be limited to a cpuset.  I
chose to use the mempolicy infrastructure because this seemed like the
best method for sending hints to the allocator, based on the first discussion.

> Yes, if it's a "simple" patch then it _might_ do a bit of swapout or
> something.  But the VM does prefer to reclaim clean pagecache first (as
> well as slab, which is a bonus for this approach).
> 
> Worth trying, at least?

Well, another limitation of this is that we then only get inactive pages
reclaimed.  When the reclaim policy is in place the allocator is going
to ignore LRU and try really hard to get local memory.

mh

-- 
Martin Hicks   ||   Silicon Graphics Inc.   ||   mort@sgi.com
--
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:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2005-05-03 13:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27 15:08 Martin Hicks
2005-04-27 17:36 ` Nikita Danilov
2005-04-28  6:33 ` Andrew Morton
2005-04-28 11:16   ` Nick Piggin
2005-04-28 11:56   ` Rik van Riel
2005-04-28 12:53     ` Martin Hicks
2005-05-03  7:17   ` Ray Bryant
2005-05-03  8:08     ` Andrew Morton
2005-05-03 13:21       ` Martin Hicks [this message]
2005-05-04  1:23         ` Andrew Morton
2005-05-12 18:53       ` Martin Hicks
2005-05-12 18:57         ` Martin Hicks

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=20050503132102.GS19244@localhost \
    --to=mort@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    --cc=raybry@engr.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox