linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Christoph Lameter <cl@linux.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Mel Gorman <mel@csn.ul.ie>, Rob Mueller <robm@fastmail.fm>,
	linux-kernel@vger.kernel.org, Bron Gondwana <brong@fastmail.fm>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [resend][PATCH] mm: increase RECLAIM_DISTANCE to 30
Date: Mon, 11 Oct 2010 20:12:26 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1010112004260.2066@chino.kir.corp.google.com> (raw)
In-Reply-To: <20101012111451.AD2E.A69D9226@jp.fujitsu.com>

On Tue, 12 Oct 2010, KOSAKI Motohiro wrote:

> > It doesn't determine what the maximum latency to that memory is, it relies 
> > on whatever was defined in the SLIT; the only semantics of that distance 
> > comes from the ACPI spec that states those distances are relative to the 
> > local distance of 10.
> 
> Right. but do we need to consider fake SLIT case? I know actually such bogus
> slit are there. but I haven't seen such fake SLIT made serious trouble.
> 

If we can make the assumption that the SLIT entries are truly 
representative of the latencies and are adhering to the semantics 
presented in the ACPI spec, then this means the VM prefers to do zone 
reclaim rather than from other nodes when the latter is 3x more costly.

That's fine by me, as I've mentioned we've done this for a couple years 
because we've had to explicitly disable zone_reclaim_mode for such 
configurations.  If that's the policy decision that's been made, though, 
we _could_ measure the cost at boot and set zone_reclaim_mode depending on 
the measured latency rather than relying on the SLIT at all in this case.

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

  reply	other threads:[~2010-10-12  3:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08  1:48 KOSAKI Motohiro
2010-10-08  9:04 ` Balbir Singh
2010-10-08 15:45   ` Christoph Lameter
2010-10-08 16:59     ` Balbir Singh
2010-10-08 17:56       ` Christoph Lameter
2010-10-12  2:11         ` David Rientjes
2010-10-12  2:17           ` KOSAKI Motohiro
2010-10-12  3:12             ` David Rientjes [this message]
2010-10-12  4:07               ` KOSAKI Motohiro
2010-10-12  6:41                 ` Balbir Singh
2010-10-12  1:55   ` KOSAKI Motohiro
2010-10-08  1:48 KOSAKI Motohiro
2010-10-25  3:24 KOSAKI Motohiro
2010-10-25  4:35 ` KAMEZAWA Hiroyuki

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=alpine.DEB.2.00.1010112004260.2066@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=brong@fastmail.fm \
    --cc=cl@linux.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=robm@fastmail.fm \
    /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