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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 22 Jul 2010 11:25:48 +0200
From:	Marek Szyprowski <m.szyprowski@...sung.com>
To:	'Mark Brown' <broonie@...nsource.wolfsonmicro.com>,
	Michal Nazarewicz <m.nazarewicz@...sung.com>
Cc:	'Daniel Walker' <dwalker@...eaurora.org>, linux-mm@...ck.org,
	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

Hello,

On Thursday, July 22, 2010 11:06 AM Mark Brown wrote:

> On Wed, Jul 21, 2010 at 08:41:12PM +0200, Micha?? Nazarewicz wrote:
> > On Wed, 21 Jul 2010 20:24:58 +0200, Mark Brown
> <broonie@...nsource.wolfsonmicro.com> wrote:
> 
> > >> I am currently working on making the whole thing more dynamic.  I
> imagine
> 
> > > 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.
> 
> > Not sure what you mean by the last sentence.  Maybe we have different
> > things in mind?
> 
> I mean that if the drivers are able to request things dynamically and
> have some knowledge of their own requirements then that removes the need
> to manually specify exactly which regions go to which drivers which
> means that most of the complexity of the existing syntax is not needed
> since it can be figured out at runtime.

The driver may specify memory requirements (like memory address range or
alignment), but it cannot provide enough information to avoid or reduce
memory fragmentation. More than one memory region can be perfectly used
to reduce memory fragmentation IF common usage patterns are known. In
embedded world usually not all integrated device are being used at the
same time. This way some memory regions can be shared by 2 or more devices. 

Just assume that gfx accelerator allocates memory is rather small chunks,
but keeps it while relevant surface is being displayed or processed by
application. It is not surprising that GUI (accelerated by the hardware
engine) is used almost all the time on a mobile device. This usage pattern
would produce a lot of fragmentation in the memory pool that is used by gfx
accelerator. Then we want to run a camera capture device to take a 8Mpix
photo. This require a large contiguous buffer. If we try to allocate it from
common pool it might happen that it is not possible (because of the
fragmentation).

With CMA approach we can create 2 memory regions for this case. One for gfx
accelerator and the other for camera capture device, video decoder or jpeg
decoder, because common usage analysis showed that these 3 devices usually
are not used at the same time.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

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