| Message ID | 1338370318.3637.12.camel@ThinkPad-T420 (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Michael Ellerman |
| Headers | show |
On Wed, May 30, 2012 at 05:31:58PM +0800, Li Zhong wrote: > I'm not sure whether it makes sense to add this dependency to avoid > CONFI_NUMA && !CONFIG_SMP. > > I want to do this because I saw some build errors on next-tree when > compiling with CONFIG_SMP disabled, and it seems they are caused by some > codes under the CONFIG_NUMA #ifdefs. This seems to make sense to me. Can you please repost with a better changelog and a description of the actual build error you were seeing. cheers
On Thu, 2013-04-18 at 11:46 +1000, Michael Ellerman wrote: > On Wed, May 30, 2012 at 05:31:58PM +0800, Li Zhong wrote: > > I'm not sure whether it makes sense to add this dependency to avoid > > CONFI_NUMA && !CONFIG_SMP. > > > > I want to do this because I saw some build errors on next-tree when > > compiling with CONFIG_SMP disabled, and it seems they are caused by some > > codes under the CONFIG_NUMA #ifdefs. > > This seems to make sense to me. Can you please repost with a better > changelog and a description of the actual build error you were seeing. I tried it today, but didn't find any build errors any more, guess those errors should have already been fixed. But it seems to me by disabling CONFIG_NUMA when CONFIG_SMP is disabled, could at least prevent some unnecessary code being compiled into the kernel. (After building a kernel with/without CONFIG_NUMA just now, it seems that the vmlinux is ~100K smaller without CONFIG_NUMA). I'm not sure whether this is still needed. Thanks, Zhong > > cheers >
On Fri, 2013-04-19 at 10:10 +0800, Li Zhong wrote: > On Thu, 2013-04-18 at 11:46 +1000, Michael Ellerman wrote: > > On Wed, May 30, 2012 at 05:31:58PM +0800, Li Zhong wrote: > > > I'm not sure whether it makes sense to add this dependency to avoid > > > CONFI_NUMA && !CONFIG_SMP. > > > > > > I want to do this because I saw some build errors on next-tree when > > > compiling with CONFIG_SMP disabled, and it seems they are caused by some > > > codes under the CONFIG_NUMA #ifdefs. > > > > This seems to make sense to me. Can you please repost with a better > > changelog and a description of the actual build error you were seeing. > > I tried it today, but didn't find any build errors any more, guess those > errors should have already been fixed. > > But it seems to me by disabling CONFIG_NUMA when CONFIG_SMP is disabled, > could at least prevent some unnecessary code being compiled into the > kernel. (After building a kernel with/without CONFIG_NUMA just now, it > seems that the vmlinux is ~100K smaller without CONFIG_NUMA). > > I'm not sure whether this is still needed. Yeah we'll leave your patch out. Unless someone cares deeply about the size of the UP build, I think it's better to just leave them as separate options. cheers
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 050cb37..b2aa74b 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -394,7 +394,7 @@ config IRQ_ALL_CPUS config NUMA bool "NUMA support" - depends on PPC64 + depends on PPC64 && SMP default y if SMP && PPC_PSERIES config NODES_SHIFT
I'm not sure whether it makes sense to add this dependency to avoid CONFI_NUMA && !CONFIG_SMP. I want to do this because I saw some build errors on next-tree when compiling with CONFIG_SMP disabled, and it seems they are caused by some codes under the CONFIG_NUMA #ifdefs. Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com> --- arch/powerpc/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)