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@xxxxxxxxx> 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 >
