Re: [PATCH v3] mm/page_reporting: Add page_reporting_delay_ms module parameter
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
>>> 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). -- Cheers, David