On Mon, Jun 08, 2026 at 10:17:47AM +0100, Lorenzo Stoakes wrote: > On Mon, Jun 08, 2026 at 04:33:46AM -0400, Michael S. Tsirkin wrote: > > Further, on architectures with aliasing caches, upstream 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. > > > > For page reporting, VIRTIO_BALLOON_F_DEVICE_INIT_REPORTED (bit 6) > > is used. For the inflate/deflate path, > > VIRTIO_BALLOON_F_DEVICE_INIT_ON_INFLATE (bit 7) is used. > > > > Virtio spec: https://lore.kernel.org/all/[email protected] > > > > Based on v7.1-rc6. When applying on mm-unstable, two conflicts > > are expected: > > - kernel_init_pages() was renamed to clear_highpages_kasan_tagged() > > in mm-unstable. Use clear_highpages_kasan_tagged() in the > > post_alloc_hook else branch. > > - FPI_PREPARED uses BIT(3) in mm-unstable. Bump FPI_ZEROED to > > BIT(4). > > Build-tested on mm-unstable at e9dd96806dbc: > > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git > > zero-mm-unstable > > > > Patches 1-5: fixes/cleanups, dependencies of the zeroing patches. > > Patches 6-9: thread user_addr through page allocator, contig API, > > and gigantic hugetlb allocation. > > Patches 10-16: folio_zero_user in post_alloc_hook, vma_alloc_zeroed > > conversion, raw fault address threading. > > Patches 17-24: PG_zeroed flag, aliasing guard, buddy merge/split > > tracking, FPI_ZEROED optimization, folio_put_zeroed. > > Patches 25-27: __GFP_ZERO callsite conversions (alloc_anon_folio, > > vma_alloc_anon_folio_pmd) with memcg charge failure mitigation. > > Patches 28-29: hugetlb __GFP_ZERO + HPG_zeroed. > > Patches 30-35: page reporting zeroing (DEVICE_INIT_REPORTED), > > disable indirect descriptors. > > Patches 36-37: inflate/deflate zeroing (DEVICE_INIT_ON_INFLATE). > > This seems far too much for one series. > > YOu're doing a bunch of mm stuff that seems relatively independent, then > putting the virtio stuff on top. > > I think this should be broken out into separate series laying foundations > rather than doing it all in one go, which is also difficult for review > purposes. > > Adding a new folio flag is contentious also for instance, we maybe want to > go bit-by-bit and ensure that each foundational element is acceptable > before doing the next bit rather than having it as part of a big series. > > Looking through the changelog only adds to this feeling! Huge numbers of > changes, even relatively recently and I'm not sure all relevant maintainers > in mm have had a look through either. > > Thanks, Lorenzo
Additionally, it seems you've missed/ignored (I hope not) a bunch of pre-existing feedback, so it'd be helpful if you'd carefully go through what people have previously asked! Keeping track of that, especially on a big series, is a lot of work. Thanks, Lorenzo
