Re: [PATCH v3] mm/page_reporting: Add page_reporting_delay_ms module parameter

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Jul 30, 2026 at 02:39:51PM +0200, David Hildenbrand (Arm) wrote:
> >>> With 2s, we wait 2s before we start reporting immediately by kicking the
> >>> workqueue immediately.
> >>>
> >>> So "0" does not mean "report all the time", rather "start reporting immediately
> >>> as we are notified about a pageblock to report".
> >
> > No, it's whenever pageblock_order is specified, defaulting to a pageblock.
> >
> > But I guess in practice fine.
> >
> > There's fun like this in virtio_balloon.c btw:
> >
> > 		/*
> > 		 * The default page reporting order is @pageblock_order, which
> > 		 * corresponds to 512MB in size on ARM64 when 64KB base page
> > 		 * size is used. The page reporting won't be triggered if the
> > 		 * freeing page can't come up with a free area like that huge.
> > 		 * So we specify the page reporting order to 5, corresponding
> > 		 * to 2MB. It helps to avoid THP splitting if 4KB base page
> > 		 * size is used by host.
> > 		 *
> > 		 * Ideally, the page reporting order is selected based on the
> > 		 * host's base page size. However, it needs more work to report
> > 		 * that value. The hard-coded order would be fine currently.
> > 		 */
> > #if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES)
> > 		vb->pr_dev_info.order = 5;
> > #endif
>
> Yes, it's really about "a large chunk of memory was freed". On 64k " a large
> chunk" is unfortunately order 5 == 2MiB (so the same as on 4k where a pageblock
> is 2M).

Yup :)

Yeah in general I'm fine then with the timeout being 0, the fact it's batched
like this makes that rather moot!

>
> --
> Cheers,
>
> David

Cheers, Lorenzo