Re: [RFC PATCH v2 3/5] rmap: add page_add_file_rmap_range()

["Yin, Fengwei" <fengwei.yin@intel.com>]

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

>