RE: [Linaro-mm-sig] [PATCH 12/15] drivers: add Contiguous Memory Allocator

Marek Szyprowski
2012-01-27T14:51:15Z

Hello,

On Friday, January 27, 2012 3:28 PM Clark, Rob wrote:

> 2012/1/27 Marek Szyprowski <m.szyprowski@samsung.com>:
> > Hi Ohad,
> >
> > On Friday, January 27, 2012 10:44 AM Ohad Ben-Cohen wrote:
> >
> >> With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
> >> In particular, this seems to fail:
> >>
> >> On Thu, Jan 26, 2012 at 11:00 AM, Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >> > +static int cma_activate_area(unsigned long base_pfn, unsigned long count)
> >> > +{
> >> > +       unsigned long pfn = base_pfn;
> >> > +       unsigned i = count >> pageblock_order;
> >> > +       struct zone *zone;
> >> > +
> >> > +       WARN_ON_ONCE(!pfn_valid(pfn));
> >> > +       zone = page_zone(pfn_to_page(pfn));
> >> > +
> >> > +       do {
> >> > +               unsigned j;
> >> > +               base_pfn = pfn;
> >> > +               for (j = pageblock_nr_pages; j; --j, pfn++) {
> >> > +                       WARN_ON_ONCE(!pfn_valid(pfn));
> >> > +                       if (page_zone(pfn_to_page(pfn)) != zone)
> >> > +                               return -EINVAL;
> >>
> >> The above WARN_ON_ONCE is triggered, and then the conditional is
> >> asserted (page_zone() retuns a "Movable" zone, whereas zone is
> >> "Normal") and the function fails.
> >>
> >> This happens to me on OMAP4 with your 3.3-rc1-cma-v19 branch (and a
> >> bunch of remoteproc/rpmsg patches).
> >>
> >> Do big allocations work for you ?
> >
> > I've tested it with 256MiB on Exynos4 platform. Could you check if the
> > problem also appears on 3.2-cma-v19 branch (I've uploaded it a few hours
> > ago) and 3.2-cma-v18? Both are available on our public repo:
> > git://git.infradead.org/users/kmpark/linux-samsung/
> >
> > The above code has not been changed since v16, so I'm really surprised
> > that it causes problems. Maybe the memory configuration or layout has
> > been changed in 3.3-rc1 for OMAP4?
>
> is highmem still an issue? I remember hitting this WARN_ON_ONCE() but
> went away after I switched to a 2g/2g vm split (which avoids highmem)

No, it shouldn't be an issue. I've tested CMA v19 on a system with 1GiB of
the memory and general purpose (global) cma region was allocated correctly
at the end of low memory. For device private regions you should take care
of correct placement by yourself, so maybe this is an issue in this case?

Ohad, could you tell a bit more about your issue? Does this 'large region'
is a device private region (declared with dma_declare_contiguous()) or is it
a global one (defined in Kconfig or cma= kernel boot parameter)?

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