Re: [RFC PATCH] mm: populate multiple PTEs if file page is large folio

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

On 1/17/2023 6:37 PM, David Hildenbrand wrote:
> On 17.01.23 10:19, Yin, Fengwei wrote:
>>
>>
>> On 1/14/2023 2:13 AM, Matthew Wilcox wrote:
>>> On Sat, Jan 14, 2023 at 12:35:38AM +0800, Yin Fengwei wrote:
>>>> The page fault number can be reduced by batched PTEs population.
>>>> The batch size of PTEs population is not allowed to cross:
>>>>    - page table boundaries
>>>>    - vma range
>>>>    - large folio size
>>>>    - fault_around_bytes
>>>
>>> I find this patch very interesting.  But is it really worth it?  Most
>>> file-backed page faults are resolved through the ->map_pages() path
>>> which is almost always filemap_map_pages(), which does something
>>> fairly similar to this already.  Do you have any performance numbers?
>>>
>> I tried the will-it-scale page_fault3:
>> https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault3.c
>> with 96 processes on a test box with 48C/86T.
>>
>> The test result got about 3.75X better with 4.1X less page fault number
>> with this patch.
>>
>> But It's a micro benchmark which shows extreme friendly case to this patch.
>>
>> I didn't see observed performance gain with other workloads. I suppose
>> shared file write operations may not be common operations? Thanks.
> 
> One question I have after reading "which does something fairly similar to this already", if both paths could be unified.
Thanks for the suggestion. I will see what I can do for it.

Regards
Yin, Fengwei

>