Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

From: Mark Rutland
Date: Fri Sep 05 2014 - 05:37:29 EST


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 <rchintakuntla@xxxxxxxxxx>
> > > >
> > > > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/