[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190109015359.GE20586@redhat.com>
Date: Tue, 8 Jan 2019 20:53:59 -0500
From: Andrea Arcangeli <aarcange@...hat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc: akpm@...ux-foundation.org, Michal Hocko <mhocko@...nel.org>,
Alexey Kardashevskiy <aik@...abs.ru>,
David Gibson <david@...son.dropbear.id.au>, mpe@...erman.id.au,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH V6 3/4] powerpc/mm/iommu: Allow migration of cma
allocated pages during mm_iommu_get
Hello,
On Tue, Jan 08, 2019 at 10:21:09AM +0530, Aneesh Kumar K.V wrote:
> @@ -187,41 +149,25 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, unsigned long ua,
> goto unlock_exit;
> }
>
> + ret = get_user_pages_cma_migrate(ua, entries, 1, mem->hpages);
In terms of gup APIs, I've been wondering if this shall become
get_user_pages_longerm(FOLL_CMA_MIGRATE). So basically moving this
CMA migrate logic inside get_user_pages_longerm.
It depends if powerpc will ever need to bail on dax and/or if other
non-powerpc vfio drivers which are already bailing on dax may also
later optionally need to avoid interfering with CMA.
Aside from the API detail above, this CMA page migration logic seems a
good solution for the problem.
Thanks,
Andrea
Powered by blists - more mailing lists