On 15.01.2026 12:18, Roger Pau Monne wrote:
> The current logic allows for up to 1G pages to be scrubbed in place, which
> can cause the watchdog to trigger in practice. Reduce the limit for
> in-place scrubbed allocations to a newly introduced define:
> CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER
> on all architectures. Also introduce a command line option to set the
> value.
>
> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed")
> Signed-off-by: Roger Pau Monné <[email protected]>
> ---
> Changes since v1:
> - Split from previous patch.
> - Introduce a command line option to set the limit.
> ---
> docs/misc/xen-command-line.pandoc | 9 +++++++++
> xen/common/page_alloc.c | 23 ++++++++++++++++++++++-
> 2 files changed, 31 insertions(+), 1 deletion(-)
If you confine the change to page_alloc.c, won't this mean that patch 2's
passing of MEMF_no_scrub will then also be bounded (in which case the need
for patch 2 would largely disappear)?
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be
> placed in, and
> optionally the maximum sub C-state to be used used. The latter only applies
> to the highest permitted C-state.
>
> +### max-order-dirty
> +> `= <integer>`
> +
> +Specify the maximum allocation order allowed when scrubbing allocated pages
> +in-place. The allocation is non-preemptive, and hence the value must be keep
> +low enough to avoid hogging the CPU for too long.
> +
> +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`.
This may end up misleading, as - despite their names - these aren't really
Kconfig settings that people could easily control in their builds.
> ### max_gsi_irqs (x86)
> > `= <integer>`
I also wonder whether your addition wouldn't more naturally go a litter
further down, by assuming / implying that the sorting used largely ignores
separator characters (underscore vs dash here).
Jan
