On Mon, Apr 16, 2012 at 9:55 PM, Christoph Lameter cl@linux.com wrote:
On Sat, 14 Apr 2012, Haojian Zhuang wrote:
On Sat, Apr 14, 2012 at 2:27 AM, Christoph Lameter cl@linux.com wrote:
On Fri, 13 Apr 2012, Haojian Zhuang wrote:
I have one question on memory migration. As we know, malloc() from user app will allocate MIGRATE_MOVABLE pages. But if we want to use this memory as DMA usage, we can't accept MIGRATE_MOVABLE type. Could we change its behavior before DMA working?
MIGRATE_MOVABLE works fine for DMA. If you keep a reference from a device driver to user pages then you will have to increase the page refcount which will in turn pin the page and make it non movable for as long as you keep the refcount.
Hi Christoph,
Thanks for your illustration. But it's a little abstract. Could you give me a simple example or show me the code?
Run get_user_pages() on the memory you are interest in pinning. See how other drivers do that by looking up other use cases. F.e. ib_umem_get() does a similar thing.
Got it. And I think there's conflict in CMA.
For example, user process A malloc() memory, page->_count is 1. After using get_user_pages() in device driver for DMA usage, page->_count becomes 2.
If the page is in CMA region, it results migrate_pages() returns -EAGAIN. But error handling in CMA is in below.
ret = alloc_contig_range(pfn, pfn + count, MIGRATE_CMA); if (ret == 0) { bitmap_set(cma->bitmap, pageno, count); break; } else if (ret != -EBUSY) { goto error; }
Since EAGAIN doesn't equal to EBUSY, dma_alloc_from_contiguous() aborts. Should dma_alloc_from_contiguous() handle EAGAIN?
Best Regards Haojian