public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] prefer allocations from nodes w/o CPUs
Date: Thu, 04 Nov 2004 17:49:53 +0000	[thread overview]
Message-ID: <200411040949.53066.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <200411040857.25664.jbarnes@engr.sgi.com>

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thursday, November 4, 2004 9:33 am, Jesse Barnes wrote:
> On Thursday, November 4, 2004 9:32 am, Alex Tsariounov wrote:
> > On Thu, Nov 04, 2004 at 10:11:19AM -0700, Alex Williamson wrote:
> > > On Thu, 2004-11-04 at 08:57 -0800, Jesse Barnes wrote:
> > > > Small patch for the ia64 version of topology.h to make the zonelist
> > > > building code prefer nodes w/o CPUs for allocations.  Do any
> > > > platforms aside from Altix have nodes with only memory?  If not, then
> > > > this will only affect sn2, otherwise I'm interested in hearing
> > > > feedback.
> > >
> > >    Yes, hp sx1000 systems represent interleaved memory in a separate
> > > node w/o cpus.
> >
> > So what's the ramifications of this patch?  Does this mean that
> > interleaved memory will now be preferably allocated over cell
> > local memory on sx1000 systems?
>
> Memory local to the node will come first, followed by the closest memory
> that doesn't have associated CPUs, followed by memory belonging to other
> CPUs.

Actually, I lied.  There's a bug in find_next_best_node that prevents the 
local node from coming first if the PENALTY_FOR_NODE_WITH_CPUS is set high 
enough.  Here's the fix (I'll send it to Andrew shortly).

Jesse

[-- Attachment #2: local-node-with-penalty-fix.patch --]
[-- Type: text/plain, Size: 446 bytes --]

===== mm/page_alloc.c 1.239 vs edited =====
--- 1.239/mm/page_alloc.c	2004-10-25 13:06:48 -07:00
+++ edited/mm/page_alloc.c	2004-11-04 09:41:23 -08:00
@@ -1213,6 +1213,12 @@
 		if (test_bit(n, used_node_mask))
 			continue;
 
+		/* Use the local node if we haven't already */
+		if (!test_bit(node, used_node_mask)) {
+			best_node = node;
+			break;
+		}
+
 		/* Use the distance array to find the distance */
 		val = node_distance(node, n);
 

  parent reply	other threads:[~2004-11-04 17:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-04 16:57 [RFC] prefer allocations from nodes w/o CPUs Jesse Barnes
2004-11-04 17:11 ` Alex Williamson
2004-11-04 17:16 ` Jesse Barnes
2004-11-04 17:22 ` Alex Williamson
2004-11-04 17:32 ` Alex Tsariounov
2004-11-04 17:33 ` Jesse Barnes
2004-11-04 17:49 ` Jesse Barnes [this message]
2004-11-04 17:59 ` Alex Tsariounov

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=200411040949.53066.jbarnes@engr.sgi.com \
    --to=jbarnes@engr.sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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