On 19.01.2026 17:13, Jan Beulich wrote:
> 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)?
This was rubbish, sorry. Besides my being thick-headed I can only attribute
this to the double negation in !(memflags & MEMF_no_scrub).
I have another concern, though: You effectively undermine ptdom_max_order,
which is even more of a problem as that would also affect Dom0's ability to
obtain larger contiguous I/O buffers. Perhaps DIRTY_MAX_ORDER ought to
default to PTDOM_MAX_ORDER (if HAS_PASSTHROUGH)? Yet then command line
options may also need tying together, such that people using
"memop-max-order=" to alter (increase) ptdom_max_order won't need to
additionally use "max-order-dirty="? At which point maybe the new option
shouldn't be a standalone one, but be added to "memop-max-order=" (despite
it being effected in alloc_heap_pages())?
Jan
