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

[David Hildenbrand <david@redhat.com>]

On 12.12.24 09:46, 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. :-)
> 
> 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.
> 
> We don't need to allocate the memory until the page is written(which may never
> happen).

I think what Christoph means is that you would determine that at PTE 
unmap time, and directly place the zero page in there. So there would be 
no need to have the page fault at all.

I suspect at PTE unmap time might be problematic, because we might still 
have other (i.e., GUP) references modifying that page, and we can only 
rely on the page content being stable after we flushed the TLB as well. 
(I recall some deferred flushing optimizations)

-- 
Cheers,

David / dhildenb