Re: [PATCH] fix build_zonelists for CONFIG_ACPI_NUMA

From: Jesse Barnes <jbarnes_at_sgi.com>
Date: 2003-09-19 06:04:02
On Thu, Sep 18, 2003 at 12:59:08PM -0700, Jesse Barnes wrote:
> On Thu, Sep 18, 2003 at 08:38:32AM -0700, Jesse Barnes wrote:
> > On Thu, Sep 18, 2003 at 05:16:33PM +0200, Erich Focht wrote:
> > > The first node in the list is fine and we'll get memory from the right
> > > node if it is free. But if not, we'll request memory from the second
> > > node in the zonelist and this will be (in most of the cases) node
> > > 1. Which means a pretty bad imbalance.
> > 
> > Yeah, that's a good point.  We should fix that.
> 
> On second thought, here's the output from a test machine here.  I think
> it's working correctly.
> 
> ...
> ACPI 2.0 SLIT locality table:
> 010 020 022 042
> 020 010 042 022
> 022 042 010 020
> 042 022 020 010
> ...
> Zonelist for node 0: 0 1 2 3
> Zonelist for node 1: 1 0 3 2
> Zonelist for node 2: 2 3 0 1
> Zonelist for node 3: 3 2 1 0
> ...
> 
> So the fallback for nodes 0 and 1 (which are in the same proximity
> domain) rotates the distant proximity domain correctly.  Same for nodes
> 2 and 3.

On third thought, I think I need to test this on a bigger machine.  I
think our machines have to get pretty big before they have nodes in the
same proximity domain (I was wrong above).   That said, I think we can
fix the problem in the sort_distance_array() routine--when we scan the
slit we should look for duplicate entries following the current node and
increment them each in succession.

Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Sep 18 16:10:32 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:17 EST