Re: [PATCH v4 0/5] batched remove rmap in try_to_unmap_one()

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

Hi Andrew, David,

On 3/14/2023 11:09 AM, Yin Fengwei wrote:
> On 3/14/23 02:49, Andrew Morton wrote:
>> On Mon, 13 Mar 2023 20:45:21 +0800 Yin Fengwei <fengwei.yin@intel.com> wrote:
>>
>>> This series is trying to bring the batched rmap removing to
>>> try_to_unmap_one(). It's expected that the batched rmap
>>> removing bring performance gain than remove rmap per page.
>>>
>>> This series reconstruct the try_to_unmap_one() from:
>>>    loop:
>>>       clear and update PTE
>>>       unmap one page
>>>       goto loop
>>> to:
>>>    loop:
>>>       clear and update PTE
>>>       goto loop
>>>    unmap the range of folio in one call
>>> It is one step to always map/unmap the entire folio in one call.
>>> Which can simplify the folio mapcount handling by avoid dealing
>>> with each page map/unmap.
>>>
>>> ...
>>>
>>> For performance gain demonstration, changed the MADV_PAGEOUT not
>>> to split the large folio for page cache and created a micro
>>> benchmark mainly as following:
>>
>> Please remind me why it's necessary to patch the kernel to actually
>> performance test this?  And why it's proving so hard to demonstrate
>> benefits in real-world workloads?
>>
>> (Yes, this was touched on in earlier discussion, but I do think these
>> considerations should be spelled out in the [0/N] changelog).
> OK. What about add following in cover letter:
> "
>  The performance gain of this series can be demonstrated with large
>  folio reclaim. In current kernel, vmscan() path will be benefited by
>  the changes. But there is no workload/benchmark can show the exact
>  performance gain for vmscan() path as far as I am aware.
> 
>  Another way to demonstrate the performance benefit is using
>  MADV_PAGEOUT which can trigger page reclaim also. The problem is that
>  MADV_PAGEOUT always split the large folio because it's not aware of
>  large folio for page cache currently. To show the performance benefit,
>  MADV_PAGEOUT is updated not to split the large folio.
> 
>  For long term with wider adoption of large folio in kernel (like large
>  folio for anonymous page), MADV_PAGEOUT needs be updated to handle
>  large folio as whole to avoid splitting it always.
> "
I just want to check how I can move this work forward. Is it enough
by adding above message? Or still need some other work be done first? Thanks.


Regards
Yin, Fengwei

> 
> 
> Regards
> Yin, Fengwei
> 
>>
>> Thanks.
>