linux-kernel - Re: [PATCH v2 1/3] ARM: Make FORCE_MAX_ZONEORDER configurable if ARM_SINGLE

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 9 Sep 2015 08:48:06 +0200
From:	Maxime Coquelin <mcoquelin.stm32@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Kevin Hilman <khilman@...nel.org>,
	Andreas Färber <afaerber@...e.de>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/3] ARM: Make FORCE_MAX_ZONEORDER configurable if ARM_SINGLE_ARMV7M

2015-09-09 0:19 GMT+02:00 Russell King - ARM Linux <linux@....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
--
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/