On 20.03.23 14:47, Yin, Fengwei wrote:
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@xxxxxxxxx> 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.
I think Andrew can add that, no need to resend. But we should see more
review (I'm fairly busy ...).
--
Thanks,
David / dhildenb