Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin

[Yosry Ahmed <yosryahmed@google.com>]

On Mon, Oct 28, 2024 at 3:52 PM Barry Song <21cnbao@gmail.com> wrote:
>
> On Tue, Oct 29, 2024 at 6:33 AM Yosry Ahmed <yosryahmed@google.com> wrote:
> >
> > [..]
> > > > > By the way, I recently had an idea: if we can conduct the zeromap check
> > > > > earlier - for example - before allocating swap slots and pageout(), could
> > > > > we completely eliminate swap slot occupation and allocation/release
> > > > > for zeromap data? For example, we could use a special swap
> > > > > entry value in the PTE to indicate zero content and directly fill it with
> > > > > zeros when swapping back. We've observed that swap slot allocation and
> > > > > freeing can consume a lot of CPU and slow down functions like
> > > > > zap_pte_range and swap-in. If we can entirely skip these steps, it
> > > > > could improve performance. However, I'm uncertain about the benefits we
> > > > > would gain if we only have 1-2% zeromap data.
> > > >
> > > > If I remember correctly this was one of the ideas floated around in the
> > > > initial version of the zeromap series, but it was evaluated as a lot more
> > > > complicated to do than what the current zeromap code looks like. But I
> > > > think its definitely worth looking into!
> >
> > Yup, I did suggest this on the first version:
> > https://lore.kernel.org/linux-mm/CAJD7tkYcTV_GOZV3qR6uxgFEvYXw1rP-h7WQjDnsdwM=g9cpAw@mail.gmail.com/
> >
> > , and Usama took a stab at implementing it in the second version:
> > https://lore.kernel.org/linux-mm/20240604105950.1134192-1-usamaarif642@gmail.com/
> >
> > David and Shakeel pointed out a few problems. I think they are
> > fixable, but the complexity/benefit tradeoff was getting unclear at
> > that point.
> >
> > If we can make it work without too much complexity, that would be
> > great of course.
> >
> > >
> > > Sorry for the noise. I didn't review the initial discussion. But my feeling
> > > is that it might be valuable considering the report from Zhiguo:
> > >
> > > https://lore.kernel.org/linux-mm/20240805153639.1057-1-justinjiang@vivo.com/
> > >
> > > In fact, our recent benchmark also indicates that swap free could account
> > > for a significant portion in do_swap_page().
> >
> > As Shakeel mentioned in a reply to Usama's patch mentioned above, we
> > would need to check the contents of the page after it's unmapped. So
> > likely we need to allocate a swap slot, walk the rmap and unmap, check
> > contents, walk the rmap again and update the PTEs, free the swap slot.
> >
>
> So the issue is that we can't check the content before allocating slots and
> unmapping during reclamation? If we find the content is zero, can we skip
> all slot operations and go directly to rmap/unmap by using a special PTE?

We need to unmap first before checking the content, otherwise the
content can change right after we check it.