linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>, Mel Gorman <mel@csn.ul.ie>,
	Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Interleave policy on 2M pages (was Re: [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of migration)
Date: Fri, 16 Apr 2010 19:51:26 +0200	[thread overview]
Message-ID: <20100416175126.GP32034@random.random> (raw)
In-Reply-To: <alpine.DEB.2.00.1004161111380.7710@router.home>

On Fri, Apr 16, 2010 at 11:13:10AM -0500, Christoph Lameter wrote:
> On Thu, 15 Apr 2010, Andrea Arcangeli wrote:
> 
> > 2) add alloc_pages_vma for numa awareness in the huge page faults
> 
> How do interleave policies work with alloc_pages_vma? So far the semantics
> is to spread 4k pages over different nodes. With 2M pages this can no
> longer work the way is was.

static struct page *alloc_page_interleave(gfp_t gfp, unsigned order,
       	      	   				     unsigned nid)

See the order parameter, so I hope it's already solved. I assume the
idea would be to interleave 2M pages to avoid the CPU the memory
overhead of the pte layer and to decrease the tlb misses, but still
maxing out the bandwidth of the system when multiple threads accesses
memory that is stored in different nodes with random access. It should
be ideal for hugetlbfs too for the large shared memory pools of the
DB. Surely it'll be better than having all hugepages from the same
node despite MPOL_INTERLEAVE is set.

Said that, it'd also be possible to disable hugepages if the vma has
MPOL_INTERLEAVE set, but I doubt we want to do that by default. Maybe
we can add a sysfs control later for that which can be further tweaked
at boot time by per-arch quirks, dunno... It's really up to you, you
know numa better, but I've no doubt that MPOL_INTERLEAVE also can make
sense with hugepages (both hugetlbfs and transparent hugepage
support).

Thanks,
Andrea

      reply	other threads:[~2010-04-16 17:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13  4:42 [RFC][BUGFIX][PATCH] memcg: fix underflow of mapped_file stat Daisuke Nishimura
2010-04-13  6:14 ` KAMEZAWA Hiroyuki
2010-04-14  0:54   ` Daisuke Nishimura
2010-04-14  1:03     ` KAMEZAWA Hiroyuki
2010-04-14  1:40       ` KAMEZAWA Hiroyuki
2010-04-14  1:56         ` KAMEZAWA Hiroyuki
2010-04-14  3:06           ` KAMEZAWA Hiroyuki
2010-04-14  5:31             ` Daisuke Nishimura
2010-04-14  5:40               ` KAMEZAWA Hiroyuki
2010-04-15  2:22                 ` Daisuke Nishimura
2010-04-13  6:45 ` Balbir Singh
2010-04-15  3:05 ` [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of migration KAMEZAWA Hiroyuki
2010-04-15  3:06   ` [RFC][BUGFIX][PATCH 2/2] memcg: fix file mapped underflow at migration (v2) KAMEZAWA Hiroyuki
2010-04-16 10:31     ` [RFC][BUGFIX][PATCH 2/2] memcg: fix file mapped underflow at migration (v3) KAMEZAWA Hiroyuki
2010-04-19  3:42       ` Daisuke Nishimura
2010-04-19  4:18         ` KAMEZAWA Hiroyuki
2010-04-19  8:07           ` Daisuke Nishimura
2010-04-19  8:26             ` KAMEZAWA Hiroyuki
2010-04-20  4:20               ` Daisuke Nishimura
2010-04-20  4:26                 ` KAMEZAWA Hiroyuki
2010-04-20  9:19                 ` KAMEZAWA Hiroyuki
2010-04-23  8:08                   ` Daisuke Nishimura
2010-04-23  8:23                     ` KAMEZAWA Hiroyuki
2010-04-15  6:43   ` [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of migration Daisuke Nishimura
2010-04-15  6:56     ` KAMEZAWA Hiroyuki
2010-04-15  8:17       ` Andrea Arcangeli
2010-04-16 16:13         ` Interleave policy on 2M pages (was Re: [RFC][BUGFIX][PATCH 1/2] memcg: fix charge bypass route of migration) Christoph Lameter
2010-04-16 17:51           ` Andrea Arcangeli [this message]

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=20100416175126.GP32034@random.random \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=cl@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).