Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jan 19, 2026 at 05:13:25PM +0100, Jan Beulich wrote:
> On 15.01.2026 12:18, Roger Pau Monne wrote:
> > --- 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.

But those have different default values depending on the architecture,
hence I didn't know what else to reference to as the default.  I'm
open to suggestions, but I think we need to reference some default
value so the user knows where to look for.

> >  ### 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).

My bad, I think I've originally named it max-dirty-order and forgot to
move it down when renaming to max-order-dirty.

Thanks, Roger.