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>
next prev parent 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