| Message ID | 1441744686-20521-2-git-send-email-mcoquelin.stm32@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Sep 08, 2015 at 10:38:04PM +0200, Maxime Coquelin wrote: > This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M > when built for a single platform. I'd prefer if we didn't do this, because this isn't supposed to be a user visible "option". It's an option that was introduced to avoid having to throw masses of #ifdefs into the definition of MAX_ZONEORDER. The problem with it is that it's a "well, what do I set this to?" option and that leads to "oh, I'll just choose the default because I don't know any better". Do we know why EFM32 needs a value of 9 here? It's not documented in the original commit, and it really _should_ have been.
On Tue, Sep 08, 2015 at 11:19:13PM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 08, 2015 at 10:38:04PM +0200, Maxime Coquelin wrote: > > This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M > > when built for a single platform. > > I'd prefer if we didn't do this, because this isn't supposed to be a user > visible "option". It's an option that was introduced to avoid having to > throw masses of #ifdefs into the definition of MAX_ZONEORDER. > > The problem with it is that it's a "well, what do I set this to?" option > and that leads to "oh, I'll just choose the default because I don't know > any better". > > Do we know why EFM32 needs a value of 9 here? It's not documented in > the original commit, and it really _should_ have been. IIRC it was done because of memory pressure. But not sure this makes any sense. I will try with the default value later today and report back. Best regards Uwe
2015-09-09 0:19 GMT+02:00 Russell King - ARM Linux <linux@arm.linux.org.uk>: > On Tue, Sep 08, 2015 at 10:38:04PM +0200, Maxime Coquelin wrote: >> This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M >> when built for a single platform. > > I'd prefer if we didn't do this, because this isn't supposed to be a user > visible "option". It's an option that was introduced to avoid having to > throw masses of #ifdefs into the definition of MAX_ZONEORDER. > > The problem with it is that it's a "well, what do I set this to?" option > and that leads to "oh, I'll just choose the default because I don't know > any better". > > Do we know why EFM32 needs a value of 9 here? It's not documented in > the original commit, and it really _should_ have been. Ok, I get your point. For STM32, the value 11 is working, but having value of 9 makes sense in my opinion for systems with small quantity of memory (8MB in the case of STM32F429 Discovery). It saves some bytes in the .data section, and it might also save some CPU cycles as there are less iterations and less split/coalescing of pages... Note that for CPU cycles I haven't done any measurements, this is just my opinion after code review. What drawbacks do you see of using a value of 9? Thanks, Maxime
On Wed, Sep 09, 2015 at 07:41:25AM +0200, Uwe Kleine-König wrote: > On Tue, Sep 08, 2015 at 11:19:13PM +0100, Russell King - ARM Linux wrote: > > On Tue, Sep 08, 2015 at 10:38:04PM +0200, Maxime Coquelin wrote: > > > This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M > > > when built for a single platform. > > > > I'd prefer if we didn't do this, because this isn't supposed to be a user > > visible "option". It's an option that was introduced to avoid having to > > throw masses of #ifdefs into the definition of MAX_ZONEORDER. > > > > The problem with it is that it's a "well, what do I set this to?" option > > and that leads to "oh, I'll just choose the default because I don't know > > any better". > > > > Do we know why EFM32 needs a value of 9 here? It's not documented in > > the original commit, and it really _should_ have been. > IIRC it was done because of memory pressure. But not sure this makes any > sense. I will try with the default value later today and report back. I updated my patch stack to 4.2 and the difference between 9 and 11 is: Using 9: / # free total used free shared buffers Mem: 3744 1688 2056 0 0 -/+ buffers: 1688 2056 vs. using 11: / # free total used free shared buffers Mem: 3744 1696 2048 0 0 -/+ buffers: 1696 2048 so it works with bearable costs. If you want to get rid of the special casing for efm32 that's fine for me. Best regards Uwe
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a750c14..88937b9 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1731,10 +1731,10 @@ config ARM_MODULE_PLTS source "mm/Kconfig" config FORCE_MAX_ZONEORDER - int "Maximum zone order" if ARCH_SHMOBILE_LEGACY + int "Maximum zone order" if ARCH_SHMOBILE_LEGACY || ARM_SINGLE_ARMV7M range 11 64 if ARCH_SHMOBILE_LEGACY default "12" if SOC_AM33XX - default "9" if SA1111 || ARCH_EFM32 + default "9" if SA1111 default "11" help The kernel memory allocator divides physically contiguous memory
This patch makes FORCE_MAX_ZONEORDER configurable in defconfig for ARMV7-M when built for a single platform. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com> --- arch/arm/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)