[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 27 Jan 2026 11:45:20 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+f62wvsoMJ+geg/xJsDNMTVEiiK0qgln2DAEwRPkCwk=; b=LpUsKEzvPDq6rTdvNWgVr16npvxYbI7QIZLIX6FlywSeHpJTfw87hPJWRBtdtGt4es8cvjWl/9DHqzcO1YrpURkbICJ2bJ4qz4mbXeoTgHdSDJMvMrJkhAo0Z9Bz50R9YqyQ1/2F4SnnhyfsdqkHXjo/+TTUI6Wntr7KcaMfqOfzI11Rn6scF+nTlN9PnhRifCwjYzt8S4DBtHwqW7xLOAhib0h/dv/RimvP6ulND3X+3REliUVlvjbHS5YlkLOg9eMjIDJzkbM1cp6UPgBTdBNn5ZUkzoNpN/uHz3NtJ0yy4BDFTviAE8aiYKaFJZQLijyKCimNxJ13n8TgImXBJw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v/zTy49v5PPjgytlJX72FD8Bk5DO8PnqwIILnt3VdQdGtQL0ap5duwihJQm+T4ben9hgUgSoYO1qxA142T2bBRvEdITp1oCO+3T0wGch1zXh6Ha5frBDh6ZKmqnAPjxDwR60TYFR2O3gvR8m5ZvIbu5Raz3lH1C8QpyraJNzB0TowydYvUusNrLPu0S0BXovE1LnnssCYpqzjFPbuCWUi0ueu/b0f9sDS4yWnt4jwgjknwR+e3g/G/FmoJuHBqEdT22pY471OoZeStntWE1Aa/kHNPArTyIFPXXLAwZRQXRjnFvQdJo+2EyWWCUaQpUmmMoaIHQzhdCXfuemzEl2Jw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 27 Jan 2026 10:45:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Jan 26, 2026 at 12:21:17PM +0100, Jan Beulich wrote:
> On 22.01.2026 18:38, 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_PTDOM_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é <roger.pau@xxxxxxxxxx>
> 
> Apart from a nit (see below) looks technically okay to me now. Still I have
> an uneasy feeling about introducing such a restriction, so I'm (still)
> hesitant to ack the change.

OK, I understand that, and I'm not going to argue there's no risk.
Overall, even if this commit is not fully correct, it's a step in the
right direction IMO, we need to limit such allocations.  And for
callers that legitimately need bigger orders we will have to add
preemptive scrubbing like we do for populate physmap.

> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -267,6 +267,13 @@ static PAGE_LIST_HEAD(page_offlined_list);
> >  /* Broken page list, protected by heap_lock. */
> >  static PAGE_LIST_HEAD(page_broken_list);
> >  
> > +/* Maximum order allowed for allocations with MEMF_no_scrub. */
> > +#ifndef CONFIG_DIRTY_MAX_ORDER
> > +# define CONFIG_DIRTY_MAX_ORDER CONFIG_PTDOM_MAX_ORDER
> > +#endif
> > +static unsigned int __ro_after_init dirty_max_order = 
> > CONFIG_DIRTY_MAX_ORDER;
> > +integer_param("max-order-dirty", dirty_max_order);
> 
> The comment may want to mention "post-boot", to account for ...
> 
> > @@ -1008,7 +1015,13 @@ static struct page_info *alloc_heap_pages(
> >  
> >      pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d);
> >      /* Try getting a dirty buddy if we couldn't get a clean one. */
> > -    if ( !pg && !(memflags & MEMF_no_scrub) )
> > +    if ( !pg && !(memflags & MEMF_no_scrub) &&
> > +         /*
> > +          * Allow any order unscrubbed allocations during boot time, we
> > +          * compensate by processing softirqs in the scrubbing loop below 
> > once
> > +          * irqs are enabled.
> > +          */
> > +         (order <= dirty_max_order || system_state < SYS_STATE_active) )
> 
> ... the system_state check here.

Added.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.