Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added

[Ankita Garg]

Hi,

On Thu, Jun 16, 2011 at 12:06:07AM +0200, Arnd Bergmann wrote:
 On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
  On 15 Jun 11 10:36, Marek Szyprowski wrote:
   On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
   
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
 I've seen this split bank allocation in Qualcomm and TI SoCs, with
 Samsung, that makes 3 major SoC vendors (I would be surprised if
 Nvidia didn't also need to do this) - so I think some configurable
 method to control allocations is necessarily. The chips can't do
 decode without it (and by can't do I mean 1080P and higher decode is
 not functionally useful). Far from special, this would appear to be
 the default.
  
  We at Qualcomm have some platforms that have memory of different
  performance characteristics, some drivers will need a way of
  specifying that they need fast memory for an allocation (and would prefer
  an error if it is not available rather than a fallback to slower
  memory). It would also be bad if allocators who don't need fast
  memory got it accidentally, depriving those who really need it.
 
 Can you describe how the memory areas differ specifically?
 Is there one that is always faster but very small, or are there
 just specific circumstances under which some memory is faster than
 another?
 
The possible conflict that I still see with per-bank CMA regions are:

* It completely destroys memory power management in cases where that
  is based on powering down entire memory banks.
   
 We already established that we have to know something about the banks,
 and your additional input makes it even clearer that we need to consider
 the bigger picture here: We need to describe parts of memory separately
 regarding general performance, device specific allocations and hotplug
 characteristics.
 
 It still sounds to me that this can be done using the NUMA properties
 that Linux already understands, and teaching more subsystems about it,
 but maybe the memory hotplug developers have already come up with
 another scheme. The way that memory hotplug and CMA choose their
 memory regions certainly needs to take both into account. As far as
 I can see there are both conflicting and synergistic effects when
 you combine the two.
 

Recently, we proposed a generic 'memory regions' framework to exploit
the memory power management capabilities on the embedded boards. Think
of some of the above CMA requirements could be met by this fraemwork.
One of the main goals of regions is to make the VM aware of the hardware
memory boundaries, like bank. For managing memory power consumption,
memory regions are created aligned to the hardware granularity at which
the power can be managed (ie, the memory power consumption operations
like on/off can be performed). If attributed are associated with each of
these regions, some of these regions could be marked as CMA-only,
ensuring that only movable and per-bank memory is allocated. More
details on the design can be found here:

http://lkml.org/lkml/2011/5/27/177
http://lkml.org/lkml/2011/6/29/202
http://lwn.net/Articles/446493/

-- 
Regards,
Ankita Garg (ank...@in.ibm.com)
Linux Technology Center
IBM India Systems  Technology Labs,
Bangalore, India
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 07/12] mm: cma: Contiguous Memory Allocator added

[Ankita Garg]

Hi Michal,

On Wed, Dec 15, 2010 at 09:34:27PM +0100, Michal Nazarewicz wrote:
 The Contiguous Memory Allocator is a set of functions that lets
 one initialise a region of memory which then can be used to perform
 allocations of contiguous memory chunks from.
 
 CMA allows for creation of private and non-private contexts.
 The former is reserved for CMA and no other kernel subsystem can
 use it.  The latter allows for movable pages to be allocated within
 CMA's managed memory so that it can be used for page cache when
 CMA devices do not use it.
 
 Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 

snip

 +/* Initialise CMA */
 +
 +unsigned long cma_reserve(unsigned long start, unsigned long size,
 +   unsigned long alignment)
 +{
 + pr_debug(%s(%p+%p/%p)\n, __func__, (void *)start, (void *)size,
 +  (void *)alignment);
 +
 + /* Sanity checks */
 + if (!size || (alignment  (alignment - 1)))
 + return (unsigned long)-EINVAL;
 +
 + /* Sanitise input arguments */
 + start = PAGE_ALIGN(start);
 + size  = PAGE_ALIGN(size);
 + if (alignment  PAGE_SIZE)
 + alignment = PAGE_SIZE;
 +
 + /* Reserve memory */
 + if (start) {
 + if (memblock_is_region_reserved(start, size) ||
 + memblock_reserve(start, size)  0)
 + return (unsigned long)-EBUSY;
 + } else {
 + /*
 +  * Use __memblock_alloc_base() since
 +  * memblock_alloc_base() panic()s.
 +  */
 + u64 addr = __memblock_alloc_base(size, alignment, 0);
 + if (!addr) {
 + return (unsigned long)-ENOMEM;
 + } else if (addr + size  ~(unsigned long)0) {
 + memblock_free(addr, size);
 + return (unsigned long)-EOVERFLOW;
 + } else {
 + start = addr;
 + }
 + }
 +

Reserving the areas of memory belonging to CMA using memblock_reserve,
would preclude that range from the zones, due to which it would not be
available for buddy allocations right ?

 + return start;
 +}
 +
 +

-- 
Regards,
Ankita Garg (ank...@in.ibm.com)
Linux Technology Center
IBM India Systems  Technology Labs,
Bangalore, India
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html