From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] fix for-loop in sn_hwperf_geoid_to_cnode()
Date: Fri, 03 Mar 2006 19:49:20 +0000 [thread overview]
Message-ID: <20060303194920.GA23999@sgi.com> (raw)
In-Reply-To: <20060303150312.GA32225@sgi.com>
On Fri, Mar 03, 2006 at 09:01:57AM -0800, Luck, Tony wrote:
> - for_each_node(cnode) {
> + for (cnode = 0; cnode < num_cnodes; cnode++) {
>
> Do we really need to fix "for_each_node()" ... having a macro
> named this way that doesn't actually loop over all nodes looks
> like an invitation to get things wrong in the future.
I don't think that will work in the short term. Once we
get to ACPI3.0, yes.
The problem is that SN & the generic kernel are not in agreement
on the definition of a "node". There are several problems.
ACPI2.0 limits the total number of nodes to 256 (PXM), SN needs
more.
In addition, it is difficult to describe IO-only nodes to the
generic kernel. We would need SRAT entries for IO-only nodes
but those tables don't currently exist. Even if they did, we still
have the 256 node limit.
As an interim & admittedly "hackey" solution, we have introduced the
notion of "cnodes". For cpu & memory nodes, the cnode number is
the same as the nid (generic kernel node number). IO nodes are
guaranteed to have numbers assigned after the last nid. IO nodes
may have number >= 256.
Only SN code is aware of cnodes. For example, IO cnodes are not in any
of the node maps: node_online_map, node_possible_map, etc.
IO cnodes don't have many (any?) of the usual per-node tables.
Perhaps for consistency, we should add an SN macro:
for_each_cnode(cnode)
or
for_each_sn_cnode(cnode) # to indicate this is SN only
All of these ugly hacks will go away when we get to ACPI3.0.
next prev parent reply other threads:[~2006-03-03 19:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-03 15:03 [PATCH] fix for-loop in sn_hwperf_geoid_to_cnode() Dean Roe
2006-03-03 17:01 ` Luck, Tony
2006-03-03 19:49 ` Jack Steiner [this message]
2006-03-03 21:52 ` Luck, Tony
2006-03-06 16:28 ` Dean Roe
2006-03-06 16:32 ` Dean Roe
2006-03-06 17:35 ` Bjorn Helgaas
2006-03-08 22:02 ` Dean Roe
2006-03-08 23:55 ` Bjorn Helgaas
2006-03-09 16:12 ` Robin Holt
2006-03-09 17:57 ` Bjorn Helgaas
2006-03-10 17:57 ` Jack Steiner
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=20060303194920.GA23999@sgi.com \
--to=steiner@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