| Message ID | 20230719135450.545227-3-ryan.roberts@arm.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Optimize large folio interaction with deferred split | expand |
On Wed, Jul 19, 2023 at 7:55 AM Ryan Roberts <ryan.roberts@arm.com> wrote: > > Like page_remove_rmap() but batch-removes the rmap for a range of pages > belonging to a folio. This can provide a small speedup due to less > manipuation of the various counters. But more crucially, if removing the > rmap for all pages of a folio in a batch, there is no need to > (spuriously) add it to the deferred split list, which saves significant > cost when there is contention for the split queue lock. > > All contained pages are accounted using the order-0 folio (or base page) > scheme. > > Reviewed-by: Yin Fengwei <fengwei.yin@intel.com> > Reviewed-by: Zi Yan <ziy@nvidia.com> > Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> I have asked for this before but let me be very clear this time: we need to generalize the existing functions rather than add more specialized functions. Otherwise it'd get even harder to maintain down the road. folio_remove_rmap_range() needs to replace page_remove_rmap(). IOW, page_remove_rmap() is just a wrapper around folio_remove_rmap_range().
On 19/07/2023 19:23, Yu Zhao wrote: > On Wed, Jul 19, 2023 at 7:55 AM Ryan Roberts <ryan.roberts@arm.com> wrote: >> >> Like page_remove_rmap() but batch-removes the rmap for a range of pages >> belonging to a folio. This can provide a small speedup due to less >> manipuation of the various counters. But more crucially, if removing the >> rmap for all pages of a folio in a batch, there is no need to >> (spuriously) add it to the deferred split list, which saves significant >> cost when there is contention for the split queue lock. >> >> All contained pages are accounted using the order-0 folio (or base page) >> scheme. >> >> Reviewed-by: Yin Fengwei <fengwei.yin@intel.com> >> Reviewed-by: Zi Yan <ziy@nvidia.com> >> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> > > I have asked for this before but let me be very clear this time: we > need to generalize the existing functions rather than add more > specialized functions. Otherwise it'd get even harder to maintain down > the road. Yeah fair enough, my fault; I wrote this before I had your feedback on the other rmap function and overlooked it when refactoring this. I'll fix it and repost. > > folio_remove_rmap_range() needs to replace page_remove_rmap(). IOW, > page_remove_rmap() is just a wrapper around folio_remove_rmap_range().
diff --git a/include/linux/rmap.h b/include/linux/rmap.h index b87d01660412..f578975c12c0 100644 --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -200,6 +200,8 @@ void page_add_file_rmap(struct page *, struct vm_area_struct *, bool compound); void page_remove_rmap(struct page *, struct vm_area_struct *, bool compound); +void folio_remove_rmap_range(struct folio *folio, struct page *page, + int nr, struct vm_area_struct *vma); void hugepage_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long address, rmap_t flags); diff --git a/mm/rmap.c b/mm/rmap.c index eb0bb00dae34..4022a3ab73a8 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1359,6 +1359,78 @@ void page_add_file_rmap(struct page *page, struct vm_area_struct *vma, mlock_vma_folio(folio, vma, compound); } +/** + * folio_remove_rmap_range - Take down PTE mappings from a range of pages. + * @folio: Folio containing all pages in range. + * @page: First page in range to unmap. + * @nr: Number of pages to unmap. + * @vma: The VM area containing the range. + * + * All pages in the range must belong to the same VMA & folio. They + * must be mapped with PTEs, not a PMD. + * + * Context: Caller holds the pte lock. + */ +void folio_remove_rmap_range(struct folio *folio, struct page *page, + int nr, struct vm_area_struct *vma) +{ + atomic_t *mapped = &folio->_nr_pages_mapped; + int nr_unmapped = 0; + int nr_mapped; + bool last; + enum node_stat_item idx; + + if (unlikely(folio_test_hugetlb(folio))) { + VM_WARN_ON_FOLIO(1, folio); + return; + } + + VM_WARN_ON_ONCE(page < &folio->page || + page + nr > (&folio->page + folio_nr_pages(folio))); + + if (!folio_test_large(folio)) { + /* Is this the page's last map to be removed? */ + last = atomic_add_negative(-1, &page->_mapcount); + nr_unmapped = last; + } else { + for (; nr != 0; nr--, page++) { + /* Is this the page's last map to be removed? */ + last = atomic_add_negative(-1, &page->_mapcount); + if (last) + nr_unmapped++; + } + + /* Pages still mapped if folio mapped entirely */ + nr_mapped = atomic_sub_return_relaxed(nr_unmapped, mapped); + if (nr_mapped >= COMPOUND_MAPPED) + nr_unmapped = 0; + } + + if (nr_unmapped) { + idx = folio_test_anon(folio) ? NR_ANON_MAPPED : NR_FILE_MAPPED; + __lruvec_stat_mod_folio(folio, idx, -nr_unmapped); + + /* + * Queue anon large folio for deferred split if at least one + * page of the folio is unmapped and at least one page is still + * mapped. + */ + if (folio_test_large(folio) && + folio_test_anon(folio) && nr_mapped) + deferred_split_folio(folio); + } + + /* + * It would be tidy to reset folio_test_anon mapping when fully + * unmapped, but that might overwrite a racing page_add_anon_rmap + * which increments mapcount after us but sets mapping before us: + * so leave the reset to free_pages_prepare, and remember that + * it's only reliable while mapped. + */ + + munlock_vma_folio(folio, vma, false); +} + /** * page_remove_rmap - take down pte mapping from a page * @page: page to remove mapping from