Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting

From: Florian Fainelli <f.fainelli@gmail.com>
To: Mike Rapoport <rppt@linux.ibm.com>
Cc: Doug Berger <opendmb@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	sboyd@kernel.org, Kevin Cernekee <cernekee@gmail.com>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	Gregory Fong <gregory.0xf0@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting
Date: Fri, 8 May 2020 14:45:56 -0700	[thread overview]
Message-ID: <d52457ab-35a0-2018-e18e-5ed99472c040@gmail.com> (raw)
In-Reply-To: <20200508214149.GB759899@linux.ibm.com>

On 5/8/2020 2:41 PM, Mike Rapoport wrote:
> On Thu, May 07, 2020 at 01:47:57PM -0700, Florian Fainelli wrote:
>>
>> On 5/7/2020 1:29 PM, Mike Rapoport wrote:
> 
> ...
> 
>>> If I understood Florian's intention correctly, the goal was to allow
>>> manual selection of the memory model for multiplatform builds that today
>>> implicitly use flatmem.
>>
>> That is correct.
>>
>>>
>>> I think that the patch below would achieve that without changing the
>>> current defaults and without forcing flatmem on the platforms that
>>> already explicitly select sparsemem.
>>
>> Agree, with your patch, we have the following:
>>
>> mutli_v7_defonfig -> FLATMEM
>> ep93xx_defconfig -> SPARSEMEM
>> rpc_defconfig -> SPARSEMEM
>> assabet_defconfig -> SPARSEMEM
>>
>> with the bonus that when you run menuconfig you can now select sparsemem
>> for a multi-platform build, which was the intention.
> 
> If there is a need to use sparsemem for the multiplatform build, then
> maybe we should consider moving to sparsemem?

For ARCH_BRCMSTB we definitively want sparsemem (hence these patches)
because of the memory map for those chips, but not having access to all
ARM platforms that are supported by the multi-platform kernel, I would
rather we stay conservative and allow platforms to select the memory
model they want. If it turns out that sparsemem is the default, I
suppose we could always change it later on. Arnd, Russell, what do you
think?

> > The increase in size for the defconfig build is about 7k and some of if
> is accounted for the .init code and data:
> 
>    text    data     bss     dec     hex filename
> 14539957        7461462  413288 22414707        1560573 vmlinux-flatmem
> 14545233        7461762  415400 22422395        156237b vmlinux-sparse-static
> 
> I don't have ARM hardware, so I cannot measure the run-time effect though. 
> 
> 
>> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>  
> Thanks!
> 
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 66a04f6f4775..b6eb1a28ca27 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -312,6 +312,9 @@ choice
>>>  config ARCH_MULTIPLATFORM
>>>  	bool "Allow multiple platforms to be selected"
>>>  	depends on MMU
>>> +	select ARCH_FLATMEM_ENABLE
>>> +	select ARCH_SPARSEMEM_ENABLE
>>> +	select ARCH_SELECT_MEMORY_MODEL
>>>  	select ARM_HAS_SG_CHAIN
>>>  	select ARM_PATCH_PHYS_VIRT
>>>  	select AUTO_ZRELADDR
>>> @@ -1515,11 +1518,14 @@ config OABI_COMPAT
>>>  config ARCH_HAS_HOLES_MEMORYMODEL
>>>  	bool
>>>  
>>> +config ARCH_FLATMEM_ENABLE
>>> +	bool
>>> +
>>>  config ARCH_SPARSEMEM_ENABLE
>>>  	bool
>>>  
>>> -config ARCH_SPARSEMEM_DEFAULT
>>> -	def_bool ARCH_SPARSEMEM_ENABLE
>>> +config ARCH_SELECT_MEMORY_MODEL
>>> +	bool
>>>  
>>>  config HAVE_ARCH_PFN_VALID
>>>  	def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>>>
>>>> -- 
>>>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>>>> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
>>>
>>
>> -- 
>> Florian
> 

-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel