linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrea Arcangeli <aarcange@redhat.com>,
	lwoodman@redhat.com
Subject: Re: [PATCH 6/8] Add __GFP_OTHER_NODE flag
Date: Tue, 22 Feb 2011 13:47:47 -0800	[thread overview]
Message-ID: <4D642F03.5040800@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1102221333100.5929@chino.kir.corp.google.com>

On 2/22/2011 1:42 PM, David Rientjes wrote:
>
> This makes the accounting worse, NUMA_LOCAL is defined as "allocation from
> local node," meaning it's local to the allocating cpu, not local to the
> node being targeted.

Local to the process really (and I defined it originally ...)  That is 
what I'm implementing

I don't think "local to some random kernel daemon which changes mappings 
on behalf of others"
makes any sense as semantics.

> Further, preferred_zone has taken on a much more significant meaning other
> than just statistics: it impacts the behavior of memory compaction and how
> long congestion timeouts are, if a timeout is taken at all, depending on
> the I/O being done on behalf of the zone.
>
> A better way to address the issue is by making sure preferred_zone is
> actually correct by using the appropriate zonelist to be passed into the
> allocator in the first place

That is what is done already (well for THP together with my other patches)
The problem is just that local_hit/miss still uses numa_node_id() and 
not the preferred zone
to do the accounting.  In most cases that's fine and intended, just not 
for these
special daemons.


-Andi

--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-02-22 21:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-21 19:07 Fix NUMA problems in transparent hugepages and KSM Andi Kleen
2011-02-21 19:07 ` [PATCH 1/8] Fix interleaving for transparent hugepages Andi Kleen
2011-02-22 15:34   ` Christoph Lameter
2011-02-22 16:29     ` Andrea Arcangeli
2011-02-22 17:11     ` Andi Kleen
2011-02-21 19:07 ` [PATCH 2/8] Change alloc_pages_vma to pass down the policy node for local policy Andi Kleen
2011-02-22 15:42   ` Christoph Lameter
2011-02-21 19:07 ` [PATCH 3/8] Preserve local node for KSM copies Andi Kleen
2011-02-22 15:47   ` Christoph Lameter
2011-02-22 16:20     ` Andrea Arcangeli
2011-02-22 17:15       ` Andi Kleen
2011-02-22 18:24     ` Andi Kleen
2011-02-21 19:07 ` [PATCH 4/8] Preserve original node for transparent huge page copies Andi Kleen
2011-02-21 19:07 ` [PATCH 5/8] Use correct numa policy node for transparent hugepages Andi Kleen
2011-02-21 19:07 ` [PATCH 6/8] Add __GFP_OTHER_NODE flag Andi Kleen
2011-02-22 21:42   ` David Rientjes
2011-02-22 21:47     ` Andi Kleen [this message]
2011-02-22 22:08       ` David Rientjes
2011-02-22 22:52         ` Andi Kleen
2011-02-21 19:07 ` [PATCH 7/8] Use GFP_OTHER_NODE for transparent huge pages Andi Kleen
2011-02-21 19:07 ` [PATCH 8/8] Add VM counters for transparent hugepages Andi Kleen
2011-02-22 16:36   ` Dave Hansen
2011-02-22 16:43     ` Andrea Arcangeli
2011-02-22 18:02       ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2011-02-23  1:51 Fix NUMA problems in transparent hugepages v2 Andi Kleen
2011-02-23  1:52 ` [PATCH 6/8] Add __GFP_OTHER_NODE flag Andi Kleen
2011-03-03  0:45 Fix NUMA problems in transparent hugepages and KSM Andi Kleen
2011-03-03  0:45 ` [PATCH 6/8] Add __GFP_OTHER_NODE flag Andi Kleen
2011-03-03  2:33   ` KAMEZAWA Hiroyuki
2011-03-03 19:59 Fix NUMA problems in transparent hugepages and KSM Andi Kleen
2011-03-03 19:59 ` [PATCH 6/8] Add __GFP_OTHER_NODE flag Andi Kleen
2011-03-07  8:34   ` KOSAKI Motohiro
2011-03-07 16:33     ` Andi Kleen
2011-03-08  0:19       ` KOSAKI Motohiro

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=4D642F03.5040800@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --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 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).