Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO

On Mon, Jan 4, 2021 at 12:11 PM David Hildenbrand [off-list ref] wrote:

quoted

Am 04.01.2021 um 20:52 schrieb Dave Hansen [off-list ref]:

On 1/4/21 11:27 AM, Matthew Wilcox wrote:

quoted

quoted

On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote:
On 12/21/20 8:30 AM, Liang Li wrote:

quoted

--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h

@@ -137,6 +137,9 @@ enum pageflags {

#endif
#ifdef CONFIG_64BIT
   PG_arch_2,
+#endif
+#ifdef CONFIG_PREZERO_PAGE
+    PG_zero,
#endif
   __NR_PAGEFLAGS,

I don't think this is worth a generic page->flags bit.

There's a ton of space in 'struct page' for pages that are in the
allocator.  Can't we use some of that space?

I was going to object to that too, but I think the entire approach is
flawed and needs to be thrown out.  It just nukes the caches in extremely
subtle and hard to measure ways, lowering overall system performance.

Yeah, it certainly can't be the default, but it *is* useful for thing
where we know that there are no cache benefits to zeroing close to where
the memory is allocated.

The trick is opting into it somehow, either in a process or a VMA.

The patch set is mostly trying to optimize starting a new process. So process/vma doesn‘t really work.

I still wonder if using tmpfs/shmem cannot somehow be used to cover the original use case of starting a new vm fast (or rebooting an existing one involving restarting the process).

If it's rebooting a VM then file-backed should be able to skip the
zeroing because the stale data exposure is only to itself. If the
memory is being repurposed to a new VM then the file needs to be
reallocated / re-zeroed just like the anonymous case.