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. > 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.
