On Mon, Jun 08, 2026 at 11:45:18AM -0400, Gregory Price wrote: > On Mon, Jun 08, 2026 at 01:13:42PM +0200, Vlastimil Babka (SUSE) wrote: > > 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. > > > > This regresses for anything that previously didn't zero on free or > alloc, which is most kernel allocations. > > I think the scope of this set has increased too much based on early > feedback to fix the userland-initiated allocations piece along with the > balloon/reporting/double-zero piece. That's making all of this > difficult to continue following.
Yeah I feel this is 3, 4 or 5 series put together, and there's a lot to discuss in each :) so it's pretty difficult to work with them all put together. These need to be deferred/separated. > > ~Gregory Thanks, Lorenzo
