All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>,
	Mike Travis <travis@sgi.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH -tip/cpus4096-v2] cpumask: fix cpumask of call_function_data
Date: Mon, 27 Oct 2008 14:02:25 +0100	[thread overview]
Message-ID: <20081027130225.GA25323@elte.hu> (raw)
In-Reply-To: <20081027125904.GA24347@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> > If there's any chance for this in v2.6.28 then only if we disable 
> > the dynamic API branch altogether [CONFIG_MAXCPUS] and keep that 
> > for v2.6.29. This means we'd bring in the API changes which should 
> > have trivial impact only - and none of the riskier changes.
> 
> in any case, i've started testing tip/cpus4096-v2 again on x86 - the 
> problem with d4de5a above was the only outstanding known issue, 
> right?

plus there are also the fixlets below.

	Ingo

-------------->
>From a14b735fb7a82bb6561449dda4067365af7ee95c Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Thu, 23 Oct 2008 14:35:31 -0700
Subject: [PATCH] cpumask: fixlets

[ from Mike ]

Here are the only changes I could find from Rusty's last patches that
apply to tip/cpus4096-v2.

* Fix NR_CPUS reference in arch/powerpc/platforms/cell/spu_base.c

* modify arch/x86/Kconfig so CONFIG_NR_CPUS is always defined.  Also it
  does not prompt if MAXSMP is set.

* change include/linux/threads.h so CONFIG_NR_CPUS is defined for those
  arch's that do not define it.

Signed-of-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-of-by: Mike Travis <travis@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/powerpc/platforms/cell/spu_base.c |    9 ++++++---
 arch/x86/Kconfig                       |    2 +-
 include/linux/threads.h                |   16 ++++++++--------
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
index a5bdb89..a876904 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -111,10 +111,13 @@ void spu_flush_all_slbs(struct mm_struct *mm)
  */
 static inline void mm_needs_global_tlbie(struct mm_struct *mm)
 {
-	int nr = (NR_CPUS > 1) ? NR_CPUS : NR_CPUS + 1;
-
 	/* Global TLBIE broadcast required with SPEs. */
-	__cpus_setall(&mm->cpu_vm_mask, nr);
+	if (NR_CPUS > 1)
+		cpumask_setall(&mm->cpu_vm_mask);
+	else {
+		cpumask_set_cpu(0, &mm->cpu_vm_mask);
+		cpumask_set_cpu(1, &mm->cpu_vm_mask);
+	}
 }
 
 void spu_associate_mm(struct spu *spu, struct mm_struct *mm)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d574cd6..a901f59 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -585,9 +585,9 @@ config MAXSMP
 	  If unsure, say N.
 
 config NR_CPUS
-	depends on SMP
  	int "Maximum number of CPUs" if SMP && !MAXSMP
  	range 2 512 if SMP && !MAXSMP
+	default "1" if !SMP
 	default "4096" if MAXSMP
  	default "32" if X86_NUMAQ || X86_SUMMIT || X86_BIGSMP || X86_ES7000
 	default "8"
diff --git a/include/linux/threads.h b/include/linux/threads.h
index 38d1a5d..052b12b 100644
--- a/include/linux/threads.h
+++ b/include/linux/threads.h
@@ -8,17 +8,17 @@
  */
 
 /*
- * Maximum supported processors that can run under SMP.  This value is
- * set via configure setting.  The maximum is equal to the size of the
- * bitmasks used on that platform, i.e. 32 or 64.  Setting this smaller
- * saves quite a bit of memory.
+ * Maximum supported processors.  Setting this smaller saves quite a
+ * bit of memory.  Use nr_cpu_ids instead of this except for static bitmaps.
  */
-#ifdef CONFIG_SMP
-#define NR_CPUS		CONFIG_NR_CPUS
-#else
-#define NR_CPUS		1
+#ifndef CONFIG_NR_CPUS
+/* FIXME: This should be fixed in the arch's Kconfig */
+#define CONFIG_NR_CPUS	1
 #endif
 
+/* Places which use this should consider cpumask_var_t. */
+#define NR_CPUS		CONFIG_NR_CPUS
+
 #define MIN_THREADS_LEFT_FOR_ROOT 4
 
 /*

  reply	other threads:[~2008-10-27 13:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-24  4:47 [PATCH -tip/cpus4096-v2] cpumask: fix cpumask of call_function_data Hiroshi Shimamoto
2008-10-24 11:05 ` Rusty Russell
2008-10-24 21:46   ` Hiroshi Shimamoto
2008-10-26 22:40     ` Rusty Russell
2008-10-30 17:44       ` Hiroshi Shimamoto
2008-10-24 11:15 ` Rusty Russell
2008-10-27 12:55   ` Ingo Molnar
2008-10-27 12:59     ` Ingo Molnar
2008-10-27 13:02       ` Ingo Molnar [this message]
2008-10-27 13:32       ` Ingo Molnar
2008-10-27 23:07         ` Hiroshi Shimamoto
2008-10-28  0:46           ` Rusty Russell
2008-10-27 22:21     ` Rusty Russell

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=20081027130225.GA25323@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=h-shimamoto@ct.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=travis@sgi.com \
    /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.