From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Fri, 5 Sep 2014 10:36:47 +0100 Subject: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family In-Reply-To: <20140905092507.GH13515@arm.com> References: <1409903205-2762-1-git-send-email-rric@kernel.org> <1409903205-2762-2-git-send-email-rric@kernel.org> <20140905083932.GD13515@arm.com> <20140905092135.GR4703@rric.localhost> <20140905092507.GH13515@arm.com> Message-ID: <20140905093647.GH2172@leverpostej> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 > > > > > > > > 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.