On 9/18/18 9:21 AM, David Gibson wrote:
On Mon, Sep 03, 2018 at 10:07:33PM +0530, Aneesh Kumar K.V wrote:
Current code doesn't do page migration if the page allocated is a compound page.
With HugeTLB migration support, we can end up allocating hugetlb pages from
CMA region. Also THP pages can be allocated from CMA region. This patch updates
the code to handle compound pages correctly.
This add a new helper get_user_pages_cma_migrate. It does one get_user_pages
with right count, instead of doing one get_user_pages per page. That avoids
reading page table multiple times. The helper could possibly used by other
subystem if we have more users.
The patch also convert the hpas member of mm_iommu_table_group_mem_t to a union.
We use the same storage location to store pointers to struct page. We cannot
update alll the code path use struct page *, because we access hpas in real mode
and we can't do that struct page * to pfn conversion in real mode.
Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com>
This approach doesn't seem quite right to me. It's specific to pages
mapped into the IOMMU. It's true that will address the obvious case
we have, of vfio-using guests fragmenting the CMA for other guests.
But AFAICT, fragmenting the CMA coud happen with *any* locked memory,
not just things that are IOMMU mapped for VFIO. So, for example a
guest not using vfio, but using -realtime mlock=on, or an unrelated
program using locked memory (e.g. gpg or something else that locks
memory for security reasons).
AFAICT this approach won't fix the problem for that case.
yes and we should be migrate away pages that we allocated out of CMA
region before we pin/mlock them. This handle the long term pin w.r.t
vfio. For mlock too we should do that.
-aneesh
