From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, Alexey Kardashevskiy <aik@ozlabs.ru>,
mpe@ellerman.id.au, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH V2 2/4] mm: Add get_user_pages_cma_migrate
Date: Thu, 6 Sep 2018 18:53:55 +0530 [thread overview]
Message-ID: <cbcae00a-e42c-0279-1ccb-9192e486abf1@linux.ibm.com> (raw)
In-Reply-To: <20180906124504.GW14951@dhcp22.suse.cz>
On 09/06/2018 06:15 PM, Michal Hocko wrote:
> On Thu 06-09-18 11:13:40, Aneesh Kumar K.V wrote:
>> This helper does a get_user_pages_fast and if it find pages in the CMA area
>> it will try to migrate them before taking page reference. This makes sure that
>> we don't keep non-movable pages (due to page reference count) in the CMA area.
>> Not able to move pages out of CMA area result in CMA allocation failures.
>
> Again, there is no user so it is hard to guess the intention completely.
> There is no documentation to describe the expected context and
> assumptions about locking etc.
>
patch 4 is the user for the new helper. I will add the documentation
update.
> As noted in the previous email. You should better describe why you are
> bypassing hugetlb pools. I assume that the reason is to guarantee a
> forward progress because those might be sitting in the CMA pools
> already, right?
>
The reason for that is explained in the code
+ struct hstate *h = page_hstate(page);
+ /*
+ * We don't want to dequeue from the pool because pool pages will
+ * mostly be from the CMA region.
+ */
+ return alloc_migrate_huge_page(h, gfp_mask, nid, NULL);
-aneesh
next prev parent reply other threads:[~2018-09-06 13:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 5:43 [RFC PATCH V2 1/4] mm: Export alloc_migrate_huge_page Aneesh Kumar K.V
2018-09-06 5:43 ` [RFC PATCH V2 2/4] mm: Add get_user_pages_cma_migrate Aneesh Kumar K.V
2018-09-06 12:45 ` Michal Hocko
2018-09-06 13:23 ` Aneesh Kumar K.V [this message]
2018-09-06 5:43 ` [RFC PATCH V2 3/4] powerpc/mm/iommu: Allow large IOMMU page size only for hugetlb backing Aneesh Kumar K.V
2018-09-06 5:43 ` [RFC PATCH V2 4/4] powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get Aneesh Kumar K.V
2018-09-06 12:53 ` Michal Hocko
2018-09-06 13:30 ` Aneesh Kumar K.V
2018-09-07 9:03 ` Michal Hocko
2018-09-07 11:15 ` Aneesh Kumar K.V
2018-09-07 11:25 ` Michal Hocko
2018-09-06 12:31 ` [RFC PATCH V2 1/4] mm: Export alloc_migrate_huge_page Michal Hocko
2018-09-06 12:35 ` Michal Hocko
2018-09-06 13:32 ` Aneesh Kumar K.V
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=cbcae00a-e42c-0279-1ccb-9192e486abf1@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=aik@ozlabs.ru \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@kernel.org \
--cc=mpe@ellerman.id.au \
/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;
as well as URLs for NNTP newsgroup(s).