On Thu, Dec 12, 2024 at 9:50 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> wrote: > > > > > > On Thu, Dec 12, 2024 at 08:37:11PM +1300, Barry Song wrote: > > > > From: Barry Song <v-songbaohua@xxxxxxxx> > > > > > > > > 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. >
