Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758949Ab0GVKwL (ORCPT ); Thu, 22 Jul 2010 06:52:11 -0400 Received: from opensource.wolfsonmicro.com ([80.75.67.52]:41055 "EHLO opensource2.wolfsonmicro.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755177Ab0GVKwH (ORCPT ); Thu, 22 Jul 2010 06:52:07 -0400 Date: Thu, 22 Jul 2010 11:52:03 +0100 From: Mark Brown To: Marek Szyprowski Cc: Michal Nazarewicz , "'Daniel Walker'" , linux-mm@kvack.org, Pawel Osciak , "'Xiaolin Zhang'" , "'Hiremath Vaibhav'" , "'Robert Fekete'" , "'Marcus Lorentzon'" , linux-kernel@vger.kernel.org, "'Kyungmin Park'" , linux-arm-msm@vger.kernel.org Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Message-ID: <20100722105203.GD4737@rakim.wolfsonmicro.main> References: <1279649724.26765.23.camel@c-dwalke-linux.qualcomm.com> <20100721135229.GC10930@sirena.org.uk> <20100721182457.GE10930@sirena.org.uk> <20100722090602.GF10930@sirena.org.uk> <000901cb297f$e28f2b10$a7ad8130$%szyprowski@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901cb297f$e28f2b10$a7ad8130$%szyprowski@samsung.com> X-Cookie: Sauron is alive in Argentina! User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2782 Lines: 49 On Thu, Jul 22, 2010 at 11:25:48AM +0200, Marek Szyprowski wrote: > 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. I do have some passing familiarity with the area, typically a lot of the features of a SoC won't get used at all at runtime on any given system. > 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 I'd expect that the devices would be able to reserve blocks of memory to play with separately to the actual allocations (ie, allocate regions like those on the command line) and things like the GPU would make use of that. I think you're already doing part of this? > 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). Sure, but none of this is saying to me that it's specifically important to supply a static configuration via this textual configuration language on the command line - half the problem is that you're trying to write the configuration down in a format which is fairly tightly constrained by needing to be there. If the configuration is more dynamic there's a lot more flexibility to either allow the system to figure things out dynamically (which will hopefully work a lot of the time, for example in your use case only the GPU really needs memory reserving). Remember also that if you can configure this at runtime (as you say you're working towards) then even if you have a fairly static configuration you can inject it into the kernel from the application layer rather than having to either hard code it in the image or bodge it in via the command line. This keeps the resource allocation joined up with the application layer (which is after all what determines the resource usage). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/