From: Christoph Lameter <cl@linux.com>
To: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
m.szyprowski@samsung.com
Subject: Re: how to avoid allocating or freeze MOVABLE memory in userspace
Date: Wed, 18 Apr 2012 08:49:24 -0500 (CDT) [thread overview]
Message-ID: <alpine.DEB.2.00.1204180845390.14709@router.home> (raw)
In-Reply-To: <CAN1soZyJ_zURkhV3aav5oQ6gU1CcQLsUsQKDe38gdOhapkc8jw@mail.gmail.com>
On Wed, 18 Apr 2012, Haojian Zhuang wrote:
> > 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.
The increase of the page count should be temporary. That is why
migrate_pages() uses -EAGAIN to signify a temporary inability to migrate
the page.
Xen uses a page flag for pinned pages. IMHO that could be generalized and
used instead of increasing the page count. Or it could be checked in
addition and change the return value of migrate_pages().
> 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?
You need to talk to the CMA developers for this one. If there is a pinned
page in that range then definitely alloc_contig_range needs to fail. In
the case of EAGAIN (and correct marking of pinned pages elsewhere in the
kernel) we could handle the EGAIN return value by trying again.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-04-18 13:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 14:35 Haojian Zhuang
2012-04-13 18:27 ` Christoph Lameter
2012-04-14 2:51 ` Haojian Zhuang
2012-04-16 13:55 ` Christoph Lameter
2012-04-18 7:36 ` Haojian Zhuang
2012-04-18 13:49 ` Christoph Lameter [this message]
2012-04-18 15:10 ` Marek Szyprowski
2012-05-11 13:27 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1204180845390.14709@router.home \
--to=cl@linux.com \
--cc=haojian.zhuang@gmail.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox