linux-kernel - Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added

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: <20100721182457.GE10930@sirena.org.uk>
Date:	Wed, 21 Jul 2010 19:24:58 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Micha?? Nazarewicz <m.nazarewicz@...sung.com>
Cc:	Daniel Walker <dwalker@...eaurora.org>, linux-mm@...ck.org,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Pawel Osciak <p.osciak@...sung.com>,
	Xiaolin Zhang <xiaolin.zhang@...el.com>,
	Hiremath Vaibhav <hvaibhav@...com>,
	Robert Fekete <robert.fekete@...ricsson.com>,
	Marcus Lorentzon <marcus.xm.lorentzon@...ricsson.com>,
	linux-kernel@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added

On Wed, Jul 21, 2010 at 04:31:35PM +0200, Micha?? Nazarewicz wrote:
> On Wed, 21 Jul 2010 15:52:30 +0200, Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:

> > If this does need to be configured per system would having platform data
> > of some kind in the kernel not be a sensible a place to do it,

> The current version (and the next version I'm working on) of the code
> has cma_defaults() call.  It is intended to be called from platform
> initialisation code to provide defaults.

So the command line is just a way of overriding that?  That makes things
a lot nicer - normally the device would use the defaults and the command
line would be used in development.

> > or even
> > having a way of configuring this at runtime (after all, the set of
> > currently active users may vary depending on the current configuration
> > and keeping everything allocated all the time may be wasteful)?

> I am currently working on making the whole thing more dynamic.  I imagine
> the list of regions would stay pretty much the same after kernel has
> started (that's because one cannot reliably allocate new big contiguous
> memory regions) but it will be possible to change the set of rules, etc.

Yes, I think it will be much easier to be able to grab the regions at
startup but hopefully the allocation within those regions can be made
much more dynamic.  This would render most of the configuration syntax
unneeded.
--
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/