On 6/8/26 13:02, Vlastimil Babka (SUSE) wrote: > On 6/8/26 10:33, Michael S. Tsirkin wrote: >> Further, on architectures with aliasing caches, upstream with init_on_alloc > > It seems those are niche architectures so we can ignore that part for perf > purposes; the other reason why user_alloc_needs_zeroing() would be true is > booting with init_on_alloc.
OK I misread how user_alloc_needs_zeroing() works wrt init_on_alloc, as it's negated. But you're changing that anyway to skip that user zeroing, right? " This series eliminates that double-zeroing by moving the zeroing into the post_alloc_hook + propagating the "host already zeroed this page" information through the buddy allocator. " So relying on "everything in buddy is zeroed" would still work I'd think. >> double-zeros user pages: once via kernel_init_pages() in >> post_alloc_hook, and again via clear_user_highpage() at the >> callsite (because user_alloc_needs_zeroing() returns true). >> This series eliminates that double-zeroing by moving the zeroing >> into the post_alloc_hook + propagating the "host >> already zeroed this page" information through the buddy allocator. > > I wonder if this whole thing would be much easier if those that would want > performance would enable only init_on_free and not init_on_alloc at the same > time. If you enable both you're paranoid and just eat the cost I guess. Then > you're maybe also paranoid so much that you wouldn't want to trust the host > zeroing anyway? > > post_alloc_hook() already has logic that if init_on_free is enabled, there's > no init during alloc. So then I think you would only need to communicate > that host zeroed some pages when the guest adds them to the buddy allocator, > and that's it? > > I.e. if we can just assume that everything in the buddy is zeroed, we don't > need all the PG_zero flag and whatnot complexity.
