linux-kernel - Re: [PATCH] ARM: keystone: allow FORCE_MAX_ZONEORDER to be configurable on Keystone

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <559588DA.4040300@ti.com>
Date:	Thu, 2 Jul 2015 14:54:18 -0400
From:	Murali Karicheri <m-karicheri2@...com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: keystone: allow FORCE_MAX_ZONEORDER to be configurable
 on Keystone

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/