On Fri, Sep 05, 2014 at 10:25:08AM +0100, Will Deacon wrote: > On Fri, Sep 05, 2014 at 10:21:35AM +0100, Robert Richter wrote: > > On 05.09.14 09:39:32, Will Deacon wrote: > > > On Fri, Sep 05, 2014 at 08:46:42AM +0100, Robert Richter wrote: > > > > From: Radha Mohan Chintakuntla <rchintakun...@cavium.com> > > > > > > > > Increase maximum numbers of cpus to 32. This relates to current > > > > maximal possible cpu number. Increasing this to 64 cpus will be a > > > > separate patch not part of this enablement patches. > > > > > > Just out of interest, does raising the current maximum limit actually > > > break > > > any existing code? If not, then doing this as two patches doesn't seem > > > worth > > > it. > > > > Increasing to 64 should be fine from the perspective of cpu mask > > implementation. Memory foot print should be the same already as this > > uses long which is 64 bit. So this wouldn't hurt. > > > > However, I felt a bit uncomfortable having a dependency here to > > enabling 64 cpus and getting this patch set upstream. Support for more > > than 32 cpus is not well tested yet and there still might be problems > > with e.g. interrupt delivery or topology. > > All I mean is, if the kernel doesn't explode on existing systems by changing > the upper limit to 64, then we should do that. If you're not comfortable > that the Thunder code can handle that, then leave the thunder default as 32, > like you do in the current patch. It just seems odd not to change the > maximum number, since it's an arbitrary limit from my perspective.
FWIW my Juno happily boots with a NR_CPUS=64 kernel. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
