linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: linux-mm <linux-mm@kvack.org>, ak@suse.com
Subject: Re: [PATCH 2.6.17-rc1-mm1 0/6] Migrate-on-fault - Overview
Date: Tue, 11 Apr 2006 11:46:30 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0604111134350.1027@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <1144441108.5198.36.camel@localhost.localdomain>

On Fri, 7 Apr 2006, Lee Schermerhorn wrote:

> Note that this mechanism can be used to migrate page cache pages that 
> were read in earlier, are no longer referenced, but are about to be
> used by a new task on another node from where the page resides.  The
> same mechanism can be used to pull anon pages along with a task when
> the load balancer decides to move it to another node.  However, that
> will require a bit more mechanism, and is the subject of another
> patch series.

The fundamental assumption in these patchsets is that memory policies are 
permanently used to control allocation. However, allocation policies may 
be temporarily set to various allocation methods in order to allocate 
certain memory structures in special ways. The policy may be reset later 
and not reflect the allocation wanted for a certain structure when the 
opportunistic or lazy migration takes place.

Maybe we can use the memory polices in the way you suggest (my 
MPOL_MF_MOVE_* flags certainly do the same but they are set by the coder 
of the user space application who is aware of what is going on !). 

But there are significant components missing to make this work the right 
way. In particular file backed pages are not allocated according to vma 
policy. Only anonymous pages are. So this would only work correctly for 
anonymous pages that are explicitly shifted onto swap. 

I think there will be mostly correct behavior for file backed pages. Most 
processes do not use policies at all and so this will move the file 
backed page to the node where the process is executing. If the process 
frequently refers to the page then the effort that was expended is 
justified. However, if the page is not frequently references then the 
effort required to migrate the page was not justified.

For some processes this has the potential to actually decreasing the 
performance, for other processes that are using memory policies to 
control the allocation of structures it may allocate the page in a way 
that the application tried to avoid because it may be using the wrong 
memory policy.

Then there is the known deficiency that memory policies do not work with 
file backed pages. I surely wish that this would be addressed first.


--
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>

  parent reply	other threads:[~2006-04-11 18:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-07 20:18 Lee Schermerhorn
2006-04-07 20:22 ` [PATCH 2.6.17-rc1-mm1 1/6] Migrate-on-fault - separate unmap from radix tree replace Lee Schermerhorn
2006-04-11 18:08   ` Christoph Lameter
2006-04-11 18:47     ` Lee Schermerhorn
2006-04-07 20:23 ` [PATCH 2.6.17-rc1-mm1 2/6] Migrate-on-fault - check for misplaced page Lee Schermerhorn
2006-04-11 18:21   ` Christoph Lameter
2006-04-11 19:28     ` Lee Schermerhorn
2006-04-11 19:33       ` Christoph Lameter
2006-04-12 16:43     ` Paul Jackson
2006-04-12 18:49       ` Lee Schermerhorn
2006-04-12 20:55         ` Paul Jackson
2006-04-07 20:23 ` [PATCH 2.6.17-rc1-mm1 3/6] Migrate-on-fault - migrate " Lee Schermerhorn
2006-04-11 18:32   ` Christoph Lameter
2006-04-11 19:51     ` Lee Schermerhorn
2006-04-07 20:24 ` [PATCH 2.6.17-rc1-mm1 4/6] Migrate-on-fault - handle misplaced anon pages Lee Schermerhorn
2006-04-07 20:26 ` [PATCH 2.6.17-rc1-mm1 5/6] Migrate-on-fault - add MPOL_MF_LAZY Lee Schermerhorn
2006-04-07 20:27 ` [PATCH 2.6.17-rc1-mm1 6/6] Migrate-on-fault - add MPOL_NOOP Lee Schermerhorn
2006-04-09  7:01 ` [PATCH 2.6.17-rc1-mm1 0/6] Migrate-on-fault - Overview Andi Kleen
2006-04-11 18:46 ` Christoph Lameter [this message]
2006-04-11 18:52   ` Andi Kleen
2006-04-11 19:03     ` Jack Steiner
2006-04-11 20:40       ` Lee Schermerhorn
2006-04-11 22:12         ` Jack Steiner
2006-04-11 20:40     ` Lee Schermerhorn
2006-04-11 20:40   ` Lee Schermerhorn

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=Pine.LNX.4.64.0604111134350.1027@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

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

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