All of lore.kernel.org
 help / color / mirror / Atom feed
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





  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 [PATCH] nodemask_t ia64 changes [6/7] 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.