From: Jesse Barnes <jbarnes@sgi.com>
To: colpatch@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nodemask_t ia64 changes [6/7]
Date: Thu, 18 Mar 2004 16:15:18 -0800 [thread overview]
Message-ID: <200403181615.18498.jbarnes@sgi.com> (raw)
In-Reply-To: <1079651085.8149.177.camel@arrakis>
On Thursday 18 March 2004 3:04 pm, Matthew Dobson wrote:
> nodemask_t-06-ia64.patch - Changes to ia64 specific code. Untested.
> Code review & testing requested.
diff -Nurp --exclude-from=/home/mcd/.dontdiff linux-2.6.4-vanilla/arch/ia64/kernel/smpboot.c linux-2.6.4-nodemask_t-ia64/arch/ia64/kernel/smpboot.c
--- linux-2.6.4-vanilla/arch/ia64/kernel/smpboot.c Wed Mar 10 18:55:24 2004
+++ linux-2.6.4-nodemask_t-ia64/arch/ia64/kernel/smpboot.c Thu Mar 11 16:02:22 2004
@@ -474,7 +474,7 @@ build_cpu_to_node_map (void)
{
int cpu, i, node;
- for(node=0; node<MAX_NUMNODES; node++)
+ for_each_node(node)
cpus_clear(node_to_cpu_mask[node]);
This is your API, so you'd probably know, but might this not end up
initializing some of the node_to_cpu_mask array? Oh, nevermind, it
looks like this won't just get online nodes...
@@ -134,11 +137,11 @@ static void __init reassign_cpu_only_nod
I'm not sure about this reassign_cpu_only_node() stuff, Bob Picco
would though...
diff -Nurp --exclude-from=/home/mcd/.dontdiff linux-2.6.4-vanilla/arch/ia64/sn/fakeprom/fpmem.c linux-2.6.4-nodemask_t-ia64/arch/ia64/sn/fakeprom/fpmem.c
--- linux-2.6.4-vanilla/arch/ia64/sn/fakeprom/fpmem.c Wed Mar 10 18:55:26 2004
+++ linux-2.6.4-nodemask_t-ia64/arch/ia64/sn/fakeprom/fpmem.c Thu Mar 11 12:01:24 2004
I'm hoping this file will eventually go away, but the change looks ok.
diff -Nurp --exclude-from=/home/mcd/.dontdiff linux-2.6.4-vanilla/arch/ia64/sn/io/machvec/pci_bus_cvlink.c linux-2.6.4-nodemask_t-ia64/arch/ia64/sn/io/machvec/pci_bus_cvlink.c
--- linux-2.6.4-vanilla/arch/ia64/sn/io/machvec/pci_bus_cvlink.c Wed Mar 10 18:55:37 2004
+++ linux-2.6.4-nodemask_t-ia64/arch/ia64/sn/io/machvec/pci_bus_cvlink.c Thu Mar 11 14:42:49 2004
@@ -791,7 +791,6 @@ sn_pci_init (void)
struct list_head *ln;
struct pci_bus *pci_bus = NULL;
struct pci_dev *pci_dev = NULL;
- extern int numnodes;
Neat, saved a bad extern.
@@ -62,7 +62,7 @@ find_lboard_nasid(lboard_t *start, nasid
(start->brd_nasid == nasid))
return start;
- if (numionodes == numnodes)
+ if (numionodes == num_online_nodes())
start = KLCF_NEXT_ANY(start);
else
start = KLCF_NEXT(start);
@@ -95,7 +95,7 @@ find_lboard_class_nasid(lboard_t *start,
(start->brd_nasid == nasid))
return start;
- if (numionodes == numnodes)
+ if (numionodes == num_online_nodes())
start = KLCF_NEXT_ANY(start);
@@ -210,7 +210,7 @@ io_module_init(void)
/*
* Second scan, look for headless/memless board hosted by compute nodes.
*/
- for (node = numnodes; node < numionodes; node++) {
+ for (node = num_online_nodes(); node < numionodes; node++) {
nasid_t nasid;
Here's the ionode stuff I was talking about...
diff -Nurp --exclude-from=/home/mcd/.dontdiff linux-2.6.4-vanilla/include/asm-ia64/numa.h linux-2.6.4-nodemask_t-ia64/include/asm-ia64/numa.h
--- linux-2.6.4-vanilla/include/asm-ia64/numa.h Wed Mar 10 18:55:25 2004
+++ linux-2.6.4-nodemask_t-ia64/include/asm-ia64/numa.h Thu Mar 11 12:01:24 2004
@@ -59,7 +59,7 @@ extern struct node_cpuid_s node_cpuid[NR
*/
extern u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
-#define node_distance(from,to) (numa_slit[from * numnodes + to])
+#define node_distance(from,to) (numa_slit[from * num_online_nodes() + to])
Might the SLIT contain offline nodes too? I can imagine that it might
for hotplug aware hardware...
/* klnuma.c */
-extern void replicate_kernel_text(int numnodes);
+extern void replicate_kernel_text(void); /* TODO: is this used??? */
extern unsigned long get_freemem_start(cnodeid_t cnode);
-extern void setup_replication_mask(int maxnodes);
+extern void setup_replication_mask(void); /* TODO: is this used??? */
Nope, it was at one time, but didn't provide much benefit (we should
probably benchmark it again on a really large system...).
Other than that, it looks ok. Now I've got to test it.
Thanks,
Jesse
next prev parent reply other threads:[~2004-03-19 0:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-18 23:04 Matthew Dobson
2004-03-19 0:15 ` Jesse Barnes [this message]
2004-03-19 1:03 ` Matthew Dobson
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=200403181615.18498.jbarnes@sgi.com \
--to=jbarnes@sgi.com \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®