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

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

On 3/2/2023 6:04 PM, David Hildenbrand wrote:
> On 01.03.23 02:44, Yin, Fengwei wrote:
>> On Tue, 2023-02-28 at 12:28 -0800, Andrew Morton wrote:
>>> On Tue, 28 Feb 2023 20:23:03 +0800 Yin Fengwei
>>> <fengwei.yin@intel.com> wrote:
>>>
>>>> Testing done with the V2 patchset in a qemu guest
>>>> with 4G mem + 512M zram:
>>>>    - kernel mm selftest to trigger vmscan() and final hit
>>>>      try_to_unmap_one().
>>>>    - Inject hwpoison to hugetlb page to trigger try_to_unmap_one()
>>>>      call against hugetlb.
>>>>    - 8 hours stress testing: Firefox + kernel mm selftest + kernel
>>>>      build.
>>>
>>> Was any performance testing done with these changes?
>> I tried to collect the performance data. But found out that it's
>> not easy to trigger try_to_unmap_one() path (the only one I noticed
>> is to trigger page cache reclaim). And I am not aware of a workload
>> can show it. Do you have some workloads suggsted to run? Thanks.
> 
> If it happens barely, why care about performance and have a "398 insertions(+), 260 deletions(-)" ?
I mean I can't find workload to trigger page cache reclaim and measure
its performance. We can do "echo 1 > /proc/sys/vm/drop_caches" to reclaim
page cache. But there is no obvious indicator which shows the advantage
of this patchset. Maybe I could try eBPF to capture some statistic of 
try_to_unmap_one()?


Regards
Yin, Fengwei

>