Thread (60 messages) 60 messages, 9 authors, 2012-02-10

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

From: m.szyprowski@samsung.com (Marek Szyprowski)
Date: 2012-01-27 14:51:16
Also in: linux-media, linux-mm, lkml

Hello,

On Friday, January 27, 2012 3:28 PM Clark, Rob wrote:
2012/1/27 Marek Szyprowski [off-list ref]:
quoted
Hi Ohad,

On Friday, January 27, 2012 10:44 AM Ohad Ben-Cohen wrote:
quoted
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
[off-list ref] wrote:
quoted
+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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help