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]
Message-Id: <201106150937.18524.arnd@arndb.de>
Date:	Wed, 15 Jun 2011 09:37:18 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Marek Szyprowski <m.szyprowski@...sung.com>,
	"'Michal Nazarewicz'" <mina86@...a86.com>,
	"'Ankita Garg'" <ankita@...ibm.com>,
	"'Daniel Walker'" <dwalker@...eaurora.org>,
	"'Jesse Barker'" <jesse.barker@...aro.org>,
	"'Mel Gorman'" <mel@....ul.ie>, linux-kernel@...r.kernel.org,
	linaro-mm-sig@...ts.linaro.org, linux-mm@...ck.org,
	"'Kyungmin Park'" <kyungmin.park@...sung.com>,
	"'KAMEZAWA Hiroyuki'" <kamezawa.hiroyu@...fujitsu.com>,
	"'Andrew Morton'" <akpm@...ux-foundation.org>,
	linux-media@...r.kernel.org
Subject: Re: [PATCH 08/10] mm: cma: Contiguous Memory Allocator added

On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
> I see your concerns, but I really wonder how to determine the properties
> of the global/default cma pool. You definitely don't want to give all
> available memory o CMA, because it will have negative impact on kernel
> operation (kernel really needs to allocate unmovable pages from time to
> time). 

Exactly. This is a hard problem, so I would prefer to see a solution for
coming up with reasonable defaults.

> The only solution I see now is to provide Kconfig entry to determine
> the size of the global CMA pool, but this still have some issues,
> especially for multi-board kernels (each board probably will have
> different amount of RAM and different memory-consuming devices
> available). It looks that each board startup code still might need to
> tweak the size of CMA pool. I can add a kernel command line option for
> it, but such solution also will not solve all the cases (afair there
> was a discussion about kernel command line parameters for memory 
> configuration and the conclusion was that it should be avoided).

The command line option can be a last resort if the heuristics fail,
but it's not much better than a fixed Kconfig setting.

How about a Kconfig option that defines the percentage of memory
to set aside for contiguous allocations?

	Arnd
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ