[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1010112004260.2066@chino.kir.corp.google.com>
Date: Mon, 11 Oct 2010 20:12:26 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc: Christoph Lameter <cl@...ux.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Mel Gorman <mel@....ul.ie>, Rob Mueller <robm@...tmail.fm>,
linux-kernel@...r.kernel.org, Bron Gondwana <brong@...tmail.fm>,
linux-mm <linux-mm@...ck.org>
Subject: Re: [resend][PATCH] mm: increase RECLAIM_DISTANCE to 30
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists