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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 4 Feb 2026 17:08:50 +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=5rlL/QmA9PSmxfC2caP4vmCOdIWVGYrjz0Tbry7EOfc=; b=eBDPLt0X/s05DVKtKDsDVTGCMoKU26bEzHDOS8FVpSzunVyZ91CjHdA8XeOiz3ImnQR6d3YKMbxv/W/LZbK6t2iWQU4Rg5aplIHj4GWcM0qVo4Ud73cXVkHAJL4wB8UqLg+86BP7hRmOJ32gwkOo/GyazQobsAXCqSQrMa3oAF1+lMjz801cfB+Zw1bY25kLNtj0iU8fIZxv43ym0J0PIUPmprlpAC8SkgAipuCznWlGFm8fVbgTQ0brjyo7oqUUa+92mYqecoI5aTZxWX5Kq6cprk6+nrXQeTJJJK7t88u/Z+kLNTxCns9NqWIbqVc70uOv5JNo3UsBu6ADoOSEBQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pjE9sxM9AAAeAgfY2Gtze2YM1RQzMUtb06BSem8KmAO6W6BuuupbWZG152t6inE43hfFU5DeeaxkfVtoV78j+c6cGJWLUunYONc5LW6/R82n0yhyiw8q76+rw66ZxljZdytEsBcnXV8Gt1gv0d1jTnOveWOTSqh7UNEEog9szImQ8tD6lq2TtU1wiGQVEN/Cf9mHBB+3h98F7YSiLnmYO+xltiVZvSobos89LaQhXn1kuZAdQaH57FxTQN7TFpfn6W4vq63z/3P4WmClkKyCfDb4F3MCqsBy3URgbe4bjUm8ydWxwBfNXTSrTSWhInz70wMcm5FvsyNm0m9Em3AdSQ==
  • 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: Wed, 04 Feb 2026 16:09:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Feb 03, 2026 at 04:00:09PM +0100, Jan Beulich wrote:
> On 30.01.2026 15:57, Roger Pau Monne wrote:
> > @@ -1117,6 +1130,14 @@ static struct page_info *alloc_heap_pages(
> >                      scrub_one_page(&pg[i], cold);
> >  
> >                  dirty_cnt++;
> > +
> > +                /*
> > +                 * Use SYS_STATE_smp_boot explicitly; ahead of that state
> > +                 * interrupts are disabled.
> > +                 */
> > +                if ( system_state == SYS_STATE_smp_boot &&
> > +                     !(dirty_cnt & 0xff) )
> > +                    process_pending_softirqs();
> >              }
> >              else
> >                  check_one_page(&pg[i]);
> 
> Coming back to this, I see two possible issues. One is that on x86 enabling
> of IRQs happens a bit earlier than setting of SYS_STATE_smp_boot. Maybe this
> isn't really a problem right now, but it could become one if the "wrong"
> thing is inserted into that window in __start_xen().

Even if IRQs are enabled a bit earlier, the watchdog is only setup
after SYS_STATE_smp_boot state is set.

> The other is that only x86 actually ever sets that state.

TBH we have never seen the watchdog triggering during initial domain
creation, so the workaround added here was out of caution.  There's a
certain amount of contention required for the watchdog to trigger, and
that scenario doesn't happen during boot, as domain creation is
serialized.

I could maybe gate the softirq processing as:

                if ( system_state < SYS_STATE_active && local_irq_enabled() &&
                     !(dirty_cnt & 0xff) )
                    process_pending_softirqs();

Or completely avoid softirq processing in alloc_heap_pages().

Thanks, Roger.



 


Rackspace

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