x86: increase CONFIG_NODES_SHIFT max to 10
in [Kernel]
|
From: Ingo Molnar on 11 Mar 2010 08:30 * David Rientjes <rientjes(a)google.com> wrote: > Some larger systems require more than 512 nodes, so increase the maximum > CONFIG_NODES_SHIFT to 10 for a new max of 1024 nodes. > > This was tested with numa=fake=64M on systems with more than 64GB of RAM. A > total of 1022 nodes were initialized. > > Successfully builds with no additional warnings on x86_64 allyesconfig. Not so here: drivers/base/node.c:169: error: negative width in bit-field ?<anonymous>? > Greg KH has queued up numa-fix-BUILD_BUG_ON-for-node_read_distance.patch > for 2.6.35 to fix the build error when CONFIG_NODES_SHIFT is set to 10. > See http://lkml.org/lkml/2010/3/10/390 erm. Alas I cannot merge it in the x86 tree without that fix being upstream. Why for v2.6.35 - shouldnt that be v2.6.34? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 11 Mar 2010 09:10 On Thu, Mar 11, 2010 at 02:23:54PM +0100, Ingo Molnar wrote: > > * David Rientjes <rientjes(a)google.com> wrote: > > > Some larger systems require more than 512 nodes, so increase the maximum > > CONFIG_NODES_SHIFT to 10 for a new max of 1024 nodes. > > > > This was tested with numa=fake=64M on systems with more than 64GB of RAM. A > > total of 1022 nodes were initialized. > > > > Successfully builds with no additional warnings on x86_64 allyesconfig. > > Not so here: > > drivers/base/node.c:169: error: negative width in bit-field ?<anonymous>? > > > Greg KH has queued up numa-fix-BUILD_BUG_ON-for-node_read_distance.patch > > for 2.6.35 to fix the build error when CONFIG_NODES_SHIFT is set to 10. > > See http://lkml.org/lkml/2010/3/10/390 Well, it will be a few days before I queue it up... > erm. Alas I cannot merge it in the x86 tree without that fix being upstream. > Why for v2.6.35 - shouldnt that be v2.6.34? If it needs to go in before .35, or it should go through Ingo's trees, I have no objection. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 11 Mar 2010 09:20 * Greg KH <gregkh(a)suse.de> wrote: > > erm. Alas I cannot merge it in the x86 tree without that fix being > > upstream. Why for v2.6.35 - shouldnt that be v2.6.34? > > If it needs to go in before .35, or it should go through Ingo's trees, I > have no objection. It does not 'need' to be in .34 but if the fix is trivial enough then you could give it a try? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 11 Mar 2010 13:00 On Thu, Mar 11, 2010 at 03:15:33PM +0100, Ingo Molnar wrote: > > * Greg KH <gregkh(a)suse.de> wrote: > > > > erm. Alas I cannot merge it in the x86 tree without that fix being > > > upstream. Why for v2.6.35 - shouldnt that be v2.6.34? > > > > If it needs to go in before .35, or it should go through Ingo's trees, I > > have no objection. > > It does not 'need' to be in .34 but if the fix is trivial enough then you > could give it a try? The fix is trivial, I'll queue it up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 11 Mar 2010 13:30 * Greg KH <gregkh(a)suse.de> wrote: > On Thu, Mar 11, 2010 at 03:15:33PM +0100, Ingo Molnar wrote: > > > > * Greg KH <gregkh(a)suse.de> wrote: > > > > > > erm. Alas I cannot merge it in the x86 tree without that fix being > > > > upstream. Why for v2.6.35 - shouldnt that be v2.6.34? > > > > > > If it needs to go in before .35, or it should go through Ingo's trees, I > > > have no objection. > > > > It does not 'need' to be in .34 but if the fix is trivial enough then you > > could give it a try? > > The fix is trivial, I'll queue it up. Thanks Greg! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: x86, k8 nb: Enable k8_northbridges unconditionally on AMD Next: Congratulations! |