On Wed, Jan 14, 2026 at 09:48:59AM +0100, Jan Beulich wrote:
> On 13.01.2026 15:01, Roger Pau Monné wrote:
> > On Fri, Jan 09, 2026 at 12:19:26PM +0100, Jan Beulich wrote:
> >> On 08.01.2026 18:55, Roger Pau Monne wrote:
> >>> --- a/xen/common/memory.c
> >>> +++ b/xen/common/memory.c
> >>> @@ -279,6 +279,18 @@ static void populate_physmap(struct memop_args *a)
> >>>
> >>> if ( unlikely(!page) )
> >>> {
> >>> + nodeid_t node = MEMF_get_node(a->memflags);
> >>> +
> >>> + if ( memory_scrub_pending(node) ||
> >>> + (node != NUMA_NO_NODE &&
> >>> + !(a->memflags & MEMF_exact_node) &&
> >>> + memory_scrub_pending(node = NUMA_NO_NODE)) )
> >>> + {
> >>> + scrub_free_pages(node);
> >>> + a->preempted = 1;
> >>> + goto out;
> >>> + }
> >>
> >> At least for order 0 requests there's no point in trying this. With the
> >> current logic, actually for orders up to MAX_DIRTY_ORDER.
> >
> > Yes, otherwise we might force the CPU to do some scrubbing work when
> > it won't satisfy it's allocation request anyway.
> >
> >> Further, from a general interface perspective, wouldn't we need to do the
> >> same for at least XENMEM_increase_reservation?
> >
> > Possibly yes. TBH I would also be fine with strictly limiting
> > XENMEM_increase_reservation to 2M order extents, even for the control
> > domain. The physmap population is the only that actually requires
> > bigger extents.
>
> Hmm, that's an option, yes, but an ABI-changing one.
I don't think it changes the ABI: Xen has always reserved the right to
block high order allocations. See for example how max_order() has
different limits depending on the domain permissions, and I would not
consider those limits part of the ABI, they can be changed from the
command line.
Thanks, Roger.
