All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Christoph Lameter <cl@linux.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	linux-numa@vger.kernel.org, akpm@linux-foundation.org,
	Mel Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@kernel.dk>,
	Hugh Dickins <hughd@google.com>,
	andi@firstfloor.org, David Rientjes <rientjes@google.com>,
	Avi Kivity <avi@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH/RFC 0/8] numa - Migrate-on-Fault
Date: Mon, 15 Nov 2010 15:21:22 +0100	[thread overview]
Message-ID: <20101115142122.GK7269@basil.fritz.box> (raw)
In-Reply-To: <alpine.DEB.2.00.1011150809030.19175@router.home>

[Adding linux-mm where this should have been in the first place]

On Mon, Nov 15, 2010 at 08:13:14AM -0600, Christoph Lameter wrote:
> On Sun, 14 Nov 2010, KOSAKI Motohiro wrote:
> 
> > Nice!
> 
> Lets not get overenthused. There has been no conclusive proof that the
> overhead introduced by automatic migration schemes is consistently less
> than the benefit obtained by moving the data. Quite to the contrary. We
> have over a decades worth of research and attempts on this issue and there
> was no general improvement to be had that way.

I agree it's not a good idea to enable this by default because
the cost of doing it wrong is too severe. But I suspect
it's a good idea to have optionally available for various workloads.

Good candidates so far:

- Virtualization with KVM (I think it's very promising for  that)
Basically this allows to keep guests local on nodes with their
own NUMA policy without having to statically bind them.

- Some HPC workloads. There were various older reports that 
it helped there.

So basically I think automatic migration would be good to have as
another option to enable in numactl.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Christoph Lameter <cl@linux.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Lee Schermerhorn <lee.schermerhorn@hp.com>,
	linux-numa@vger.kernel.org, akpm@linux-foundation.org,
	Mel Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@kernel.dk>,
	Hugh Dickins <hughd@google.com>,
	andi@firstfloor.org, David Rientjes <rientjes@google.com>,
	Avi Kivity <avi@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH/RFC 0/8] numa - Migrate-on-Fault
Date: Mon, 15 Nov 2010 15:21:22 +0100	[thread overview]
Message-ID: <20101115142122.GK7269@basil.fritz.box> (raw)
In-Reply-To: <alpine.DEB.2.00.1011150809030.19175@router.home>

[Adding linux-mm where this should have been in the first place]

On Mon, Nov 15, 2010 at 08:13:14AM -0600, Christoph Lameter wrote:
> On Sun, 14 Nov 2010, KOSAKI Motohiro wrote:
> 
> > Nice!
> 
> Lets not get overenthused. There has been no conclusive proof that the
> overhead introduced by automatic migration schemes is consistently less
> than the benefit obtained by moving the data. Quite to the contrary. We
> have over a decades worth of research and attempts on this issue and there
> was no general improvement to be had that way.

I agree it's not a good idea to enable this by default because
the cost of doing it wrong is too severe. But I suspect
it's a good idea to have optionally available for various workloads.

Good candidates so far:

- Virtualization with KVM (I think it's very promising for  that)
Basically this allows to keep guests local on nodes with their
own NUMA policy without having to statically bind them.

- Some HPC workloads. There were various older reports that 
it helped there.

So basically I think automatic migration would be good to have as
another option to enable in numactl.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-11-15 14:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 19:44 [PATCH/RFC 0/8] numa - Migrate-on-Fault Lee Schermerhorn
2010-11-11 19:44 ` [PATCH/RFC 1/8] numa - Migrate-on-Fault - add Kconfig option Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 2/8] numa - Migrate-on-Fault - add cpuset control Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 3/8] numa - Migrate-on-Fault - check for misplaced page Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 4/8] numa - Migrate-on-Fault - migrate misplaced pages Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 5/8] numa - Migrate-on-Fault - migrate misplaced anon pages Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 6/8] numa - Migrate-on-Fault - add mbind() MPOL_MF_LAZY flag Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 7/8] numa - Migrate-on-Fault - mbind() NOOP policy Lee Schermerhorn
2010-11-11 19:45 ` [PATCH/RFC 8/8] numa - Migrate-on-Fault - add statistics Lee Schermerhorn
2010-11-14  6:37 ` [PATCH/RFC 0/8] numa - Migrate-on-Fault KOSAKI Motohiro
2010-11-15 14:13   ` Christoph Lameter
2010-11-15 14:21     ` Andi Kleen [this message]
2010-11-15 14:21       ` Andi Kleen
2010-11-15 14:37       ` Andrea Arcangeli
2010-11-15 14:33     ` Andrea Arcangeli
2010-11-17 17:03       ` Lee Schermerhorn
2010-11-17 21:27         ` Andrea Arcangeli
2010-11-16  4:54     ` KOSAKI Motohiro
2010-11-16  4:54       ` KOSAKI Motohiro
2010-11-17 14:45       ` Lee Schermerhorn
2010-11-17 17:10 ` Avi Kivity
2010-11-17 17:34   ` 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=20101115142122.GK7269@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=cl@linux.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=lee.schermerhorn@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-numa@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=npiggin@kernel.dk \
    --cc=rientjes@google.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.