Re: [PATCH] cma: allow concurrent cma pages allocation for multi-cma areas

[Laura Abbott]

On 06/05/2015 10:19 AM, MichaÅ Nazarewicz wrote:
> On Fri, Jun 05 2015, Laura Abbott wrote:
> > On 06/05/2015 01:01 AM, Weijie Yang wrote:
> > > Currently we have to hold the single cma_mutex when alloc cma pages,
> > > it is ok when there is only one cma area in system.
> > > However, when there are several cma areas, such as in our Android smart
> > > phone, the single cma_mutex prevents concurrent cma page allocation.
> > >
> > > This patch removes the single cma_mutex and uses per-cma area alloc_lock,
> > > this allows concurrent cma pages allocation for different cma areas while
> > > protects access to the same pageblocks.
> > >
> > > Signed-off-by: Weijie Yang <weijie.yang@xxxxxxxxxxx>
>
> > Last I knew alloc_contig_range needed to be serialized which is why we
> > still had the global CMA mutex. https://lkml.org/lkml/2014/2/18/462
> >
> > So NAK unless something has changed to allow this.
>
> This patch should be fine.
>
> Change youâve pointed to would get rid of any serialisation around
> alloc_contig_range which is dangerous, but since CMA regions are
> pageblock-aligned:
>
>      /*
>       * Sanitise input arguments.
>       * Pages both ends in CMA area could be merged into adjacent unmovable
>       * migratetype page by page allocator's buddy algorithm. In the case,
>       * you couldn't get a contiguous memory, which is not what we want.
>       */
>      alignment = max(alignment,
>          (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order));
>      base = ALIGN(base, alignment);
>      size = ALIGN(size, alignment);
>      limit &= ~(alignment - 1);
>
> synchronising allocation in each area should work fine.

Okay yes, you are correct. I was somehow thinking that different CMA regions
could end up in the same pageblock. This is documented in alloc_contig_range
but can we put a comment explaining this here too? It seems to come up
every time locking here is discussed.

Thanks,
Laura

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/