Re: [PATCH RFC] mm: map zero-filled pages to zero_pfn while doing swap-in

[Barry Song <21cnbao@gmail.com>]

On Thu, Dec 12, 2024 at 9:50 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Dec 12, 2024 at 09:46:03PM +1300, Barry Song wrote:
> > On Thu, Dec 12, 2024 at 9:29 PM Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > > On Thu, Dec 12, 2024 at 08:37:11PM +1300, Barry Song wrote:
> > > > From: Barry Song <v-songbaohua@oppo.com>
> > > >
> > > > While developing the zeromap series, Usama observed that certain
> > > > workloads may contain over 10% zero-filled pages. This may present
> > > > an opportunity to save memory by mapping zero-filled pages to zero_pfn
> > > > in do_swap_page(). If a write occurs later, do_wp_page() can
> > > > allocate a new page using the Copy-on-Write mechanism.
> > >
> > > Shouldn't this be done during, or rather instead of swap out instead?
> > > Swapping all zero pages out just to optimize the in-memory
> > > representation on seems rather backwards.
> >
> > I’m having trouble understanding your point—it seems like you might
> > not have fully read the code. :-)
>
> I've not read the code at all, I've read your commit log.
>
> > The situation is as follows: for a zero-filled page, we are currently
> > allocating a new
> > page unconditionally. By mapping this zero-filled page to zero_pfn, we could
> > save the memory used by this page.
>
> Yes.  But why do that in swap-in and not swap-out?

Usama implemented this in swap-out, where no I/O occurs after
his zeromap series. A bit is set in the swap->zeromap bitmap if
the swapped-out page is zero-filled. and all swapp-out I/O is
skipped.

Now, the situation is that when we re-access a swapped-out
page, we don’t always need to allocate a new page. Instead,
we can map it to zero_pfn and defer the allocation until the
page is written.

>