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);
next prev 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