From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754239AbbGBSyy (ORCPT ); Thu, 2 Jul 2015 14:54:54 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:37560 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754105AbbGBSyt (ORCPT ); Thu, 2 Jul 2015 14:54:49 -0400 Message-ID: <559588DA.4040300@ti.com> Date: Thu, 2 Jul 2015 14:54:18 -0400 From: Murali Karicheri Organization: Texas Instruments User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: , Subject: Re: [PATCH] ARM: keystone: allow FORCE_MAX_ZONEORDER to be configurable on Keystone References: <1435773182-23074-1-git-send-email-m-karicheri2@ti.com> <20150701184842.GM7557@n2100.arm.linux.org.uk> In-Reply-To: <20150701184842.GM7557@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Russell, On 07/01/2015 02:48 PM, Russell King - ARM Linux wrote: > On Wed, Jul 01, 2015 at 01:53:02PM -0400, Murali Karicheri wrote: >> Currently for Keystone devices, user can't change the >> value of CONFIG_FORCE_MAX_ZONEORDER option in defconfig. >> Users require capability to tune the value of this option on a target >> board. So this patch adds this capability > > No they shouldn't. If we do permit this, it should not be unrestricted - > it's a power-of-2 of the page size, so specifying something like 32768 is > insane. > Thanks for your comments This was present in out internal version of the kernel. Only thing I can recall is that this patch was added to fix an isue in a DEBUG buid. Memory allocation for a large data structures used by a driver during probe (internal version) was failing as the data structure gets expanded as a result of DEBUG option related variables. There is no hurry to add this for now. > In any case, it's well known that the Linux MM system fragments memory, > and the higher order allocations will fail soon after boot - and the > larger the order, the greater chance of it failing.Ok > Agree > The only case that you want large allocations is for things like DMA, and > we have a separate allocator for that called CMA, which is able to grab > large chunks of memory, provided it's configured with a large enough zone. > > Please check whether CMA can be used _before_ considering using this > option. If you need to increase the order, it should be justified, and > it should be done on a per SoC basis in a static way, not left to the > user to dream up some power-of-2 figure. I will explore these options when we upstream the internal driver. For now I will drop this patch. Thanks -- Murali Karicheri Linux Kernel, Keystone