| Message ID | 20181121092259.16482-1-aneesh.kumar@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region | expand |
On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region Asterisk in title is strange? > ppc64 use CMA area for the allocation of guest page table (hash page table). We won't > be able to start guest if we fail to allocate hash page table. We have observed > hash table allocation failure because we failed to migrate pages out of CMA region > because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins > the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we > won't be able to migrate those pages. The pages are also pinned for the lifetime of the > guest. > > Currently we support migration of non-compound pages. With THP and with the addition of > hugetlb migration we can end up allocating compound pages from CMA region. This > patch series add support for migrating compound pages. The first path adds the helper > get_user_pages_cma_migrate() which pin the page making sure we migrate them out of > CMA region before incrementing the reference count. Very little review activity. Perhaps Andrey and/or Michal can find the time.. > mm/migrate.c | 108 ++++++++++++++++++++++++++++++++++++++++ can we make this code disappear when CONFIG_CMA=n?
On 12/8/18 4:42 AM, Andrew Morton wrote: > On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > >> Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region > > Asterisk in title is strange? My mistake while editing git-format-patch cover-letter. > >> ppc64 use CMA area for the allocation of guest page table (hash page table). We won't >> be able to start guest if we fail to allocate hash page table. We have observed >> hash table allocation failure because we failed to migrate pages out of CMA region >> because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins >> the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we >> won't be able to migrate those pages. The pages are also pinned for the lifetime of the >> guest. >> >> Currently we support migration of non-compound pages. With THP and with the addition of >> hugetlb migration we can end up allocating compound pages from CMA region. This >> patch series add support for migrating compound pages. The first path adds the helper >> get_user_pages_cma_migrate() which pin the page making sure we migrate them out of >> CMA region before incrementing the reference count. > > Very little review activity. Perhaps Andrey and/or Michal can find the > time.. > >> mm/migrate.c | 108 ++++++++++++++++++++++++++++++++++++++++ > > can we make this code disappear when CONFIG_CMA=n? > We can definitely do static inline int get_user_pages_cma_migrate(unsigned long start, int nr_pages, int write, struct page **pages) { return get_user_pages_fast(start, nr_pages, write, pages); } with #ifdef CONFIG_CMA around but that is unnecessary #ifdef in the code. If CMA config is disabled, we will not be doing any migrate. Hence wondering whether we need an alternative definition for CONFIG_CMA=n -aneesh
On Fri 07-12-18 15:12:26, Andrew Morton wrote: > On Wed, 21 Nov 2018 14:52:56 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote: > > > Subject: [PATCH V4 0/3] * mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region > > Asterisk in title is strange? > > > ppc64 use CMA area for the allocation of guest page table (hash page table). We won't > > be able to start guest if we fail to allocate hash page table. We have observed > > hash table allocation failure because we failed to migrate pages out of CMA region > > because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins > > the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we > > won't be able to migrate those pages. The pages are also pinned for the lifetime of the > > guest. > > > > Currently we support migration of non-compound pages. With THP and with the addition of > > hugetlb migration we can end up allocating compound pages from CMA region. This > > patch series add support for migrating compound pages. The first path adds the helper > > get_user_pages_cma_migrate() which pin the page making sure we migrate them out of > > CMA region before incrementing the reference count. > > Very little review activity. Perhaps Andrey and/or Michal can find the > time.. I will unlikely find some time before the end of the year. Sorry about that.
ppc64 use CMA area for the allocation of guest page table (hash page table). We won't be able to start guest if we fail to allocate hash page table. We have observed hash table allocation failure because we failed to migrate pages out of CMA region because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we won't be able to migrate those pages. The pages are also pinned for the lifetime of the guest. Currently we support migration of non-compound pages. With THP and with the addition of hugetlb migration we can end up allocating compound pages from CMA region. This patch series add support for migrating compound pages. The first path adds the helper get_user_pages_cma_migrate() which pin the page making sure we migrate them out of CMA region before incrementing the reference count. Changes from V3: * Move the hugetlb check before transhuge check * Use compound head page when isolating hugetlb page Aneesh Kumar K.V (3): mm: Add get_user_pages_cma_migrate powerpc/mm/iommu: Allow migration of cma allocated pages during mm_iommu_get powerpc/mm/iommu: Allow large IOMMU page size only for hugetlb backing arch/powerpc/mm/mmu_context_iommu.c | 140 ++++++++-------------------- include/linux/hugetlb.h | 2 + include/linux/migrate.h | 3 + mm/hugetlb.c | 4 +- mm/migrate.c | 132 ++++++++++++++++++++++++++ 5 files changed, 179 insertions(+), 102 deletions(-)