On 2/2/2023 1:32 AM, Matthew Wilcox wrote: > On Wed, Feb 01, 2023 at 04:17:35PM +0800, Yin Fengwei wrote: >> /** >> - * page_add_file_rmap - add pte mapping to a file page >> - * @page: the page to add the mapping to >> + * page_add_file_rmap_range - add pte mapping to a sub page range of a folio >> + * @folio: The filio to add the mapping to >> + * @start: The first sub page index in folio >> + * @nr_pages: The number of sub pages from the first page >> * @vma: the vm area in which the mapping is added >> * @compound: charge the page as compound or small page >> * >> + * The sub page range of folio is defined by >> + * [first_sub_page, first_sub_page + nr_pages) > > Lose the "sub" from all of this. That's legacy thinking; pages are > pages and folios are folios. "subpages" was from when we were trying > to use the word "page" for both "the allocation" and "the PAGE_SIZE > range of bytes". OK. Will remove sub in next version. > >> + * >> * The caller needs to hold the pte lock. >> */ >> -void page_add_file_rmap(struct page *page, struct vm_area_struct *vma, >> - bool compound) >> +void page_add_file_rmap_range(struct folio *folio, unsigned long start, >> + unsigned int nr_pages, struct vm_area_struct *vma, >> + bool compound) > > I think this function needs to be called folio_add_file_rmap() Yes. Maybe a followup patch after this series? Let me know if you want this change in this series. > > I'd like to lose the 'compound' parameter, and base it on nr_pages == > folio_nr_pages(), but that may be a step far just now. Yes. I had a local change to remove if (folio_test_pmd_mappable(folio)) test (It's very close to removing 'compound'). I didn't include it in this series. I prefer a follow up patch. Let me know if you want the change in this series. Thanks. Regards Yin, Fengwei >
