[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57C9024A16AD2D4C97DC78E552063EA39EC57748@orsmsx505.amr.corp.intel.com>
Date: Tue, 21 Apr 2009 11:45:28 -0700
From: "Luck, Tony" <tony.luck@...el.com>
To: Pekka Enberg <penberg@...helsinki.fi>,
Christoph Lameter <cl@...ux.com>
CC: Nick Piggin <npiggin@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"randy.dunlap_ocs10g@...cle.com" <randy.dunlap_ocs10g@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Mundt <lethal@...ux-sh.org>,
"iwamatsu.nobuhiro@...esas.com" <iwamatsu.nobuhiro@...esas.com>
Subject: RE: linux-next ia64 build problems in slqb
> Interesting. What exactly is an UP NUMA machine?
UP + NUMA is a special case of memory-only nodes. There are
some (crazy?) customers with problems that require very large
amounts of memory, but not very much cpu horse power. They
buy large multi-node systems and populate all the nodes with
as much memory as they can afford, but most nodes get zero
cpus.
The limit case with only one cpu is becoming rare (since
multi-core gives you more than one cpu even if you only
fill a single cpu socket).
N.B. Note that memory only nodes mean that it is a poor
idea for the "free" code to just place returned remote
memory on a queue for the node that it belongs to, and
rely on a "local" cpu processing that queue ... there may
not be any local cpus to do so.
> Anyway, I'm more than
> happy to apply a tested patch to fix up SLQB. Nick?
I'm trying to check whether http://lkml.org/lkml/2009/4/20/30
fixes things. It certainly solves the complilation problem,
but I'm running into apparently unrelated issues trying to
boot linux-next kernels.
-Tony
--
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