[RFC] arm64: force CONFIG_SMP=y and remove redundant #ifdefs

Commit Message

Catalin Marinas July 8, 2015, 10:58 a.m. UTC

On Tue, Jul 07, 2015 at 07:26:15PM +0100, Will Deacon wrote:
> Nobody seems to be producing !SMP systems anymore, so this is just
> becoming a source of kernel bugs, particularly if people want to use
> coherent DMA with non-shared pages.
> 
> This patch forces CONFIG_SMP=y for arm64, removing a modest amount of
> code in the process.
> 
> Signed-off-by: Will Deacon <[e-mail]>
> ---
> 
> I'd appreciate any comments on this. Anybody got a good reason for
> CONFIG_SMP=n on arm64?

A good reason would be testing/validating some hardware configurations
or even KVM/Xen (to see how they cope with UP OS'es). Of course, this
still requires that someone tests UP builds regularly but at least under
KVM this shouldn't be hard.

An alternative, which does not remove any code:


The help text needs re-writing as well, it doesn't make much sense these
days.

Comments

Will Deacon July 8, 2015, 2:09 p.m. UTC | #1

On Wed, Jul 08, 2015 at 11:58:47AM +0100, Catalin Marinas wrote:
> On Tue, Jul 07, 2015 at 07:26:15PM +0100, Will Deacon wrote:
> > Nobody seems to be producing !SMP systems anymore, so this is just
> > becoming a source of kernel bugs, particularly if people want to use
> > coherent DMA with non-shared pages.
> > 
> > This patch forces CONFIG_SMP=y for arm64, removing a modest amount of
> > code in the process.
> > 
> > Signed-off-by: Will Deacon <[e-mail]>
> > ---
> > 
> > I'd appreciate any comments on this. Anybody got a good reason for
> > CONFIG_SMP=n on arm64?
> 
> A good reason would be testing/validating some hardware configurations
> or even KVM/Xen (to see how they cope with UP OS'es). Of course, this
> still requires that someone tests UP builds regularly but at least under
> KVM this shouldn't be hard.

From a hypervisor perspective, this "validation" is basically just checking
that memory is overridden to be shareable and TLB/cache maintenance is
forced to be broadcast, right?

However, I think a UP kernel should be doing that *anyway* in order to
support cache-coherent DMA (potentially behind an SMMU using CPU page
tables), so by the time you fix !SMP kernels to do all that, they're
basically indistinguishable imo.

> An alternative, which does not remove any code:

Bah, removing the code is what made it fun :)

Will

Patch

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f62c24..8610effa5b0d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -475,7 +475,8 @@  config CPU_BIG_ENDIAN
          Say Y if you plan on running a kernel in big-endian mode.
 
 config SMP
-	bool "Symmetric Multi-Processing"
+	bool "Symmetric Multi-Processing" if EXPERT
+	default y
 	help
 	  This enables support for systems with more than one CPU.  If
 	  you say N here, the kernel will run on single and