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

Re: [PATCH] dom0/pvh: fix processing softirqs during memory map population


  • To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 7 Feb 2022 09:21:11 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=mTscNh/07aaJzB8pmmM9mgW6InXgsKWxhdU4rgAVIqw=; b=gCA+vkv5Su90lOlBXDA70uyjkvmuVowO6oAa2HPq9Z0dCMSoBJAKyv6v8thsl6JemrT7mHv3m8M6wHo0+fhMM37oMfx+CVup90Wo5UzSonLWVDJy5KNfzd2GkiHSFjFMNWID0+OujIEHm/SZgIJeKbMSqQ/cSLQl+zwrvrYBdcZAvBU5S4aGQO9IST35DiSX4LS7QrczE8ebA+TXH9dw9CGUptaeH5fiRe9+akaOCMGVmoHCc+np5FblAknjMz5xHyA/5PI8TGMcxNGahiBxklmq/4i+37yj4prll0sAwlYCdgcVhMKrfSFD8bdr1aK9tcWHybXPcgwRxjTJzGw/DA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fTltv12dAhhfy7nlhftL8xwjQDuQBgTQkAnK4hXaO10Bv4yfLJYKSLYCnPgxlHeCsf9RwZECCKJsKUq/6MGf+FYnHmuwcJToXaxKnNFYq1HRoxI6k35wzmtb3Cp9NU5Wc8pZHC1s3vbw4/jwNYnarJcaVjomLQR6fhT1wnSNIYGD3wu1ulTu/BjSlWziQgjAI7LFE2Yaq1bpCWyl67S5kTB/qe/s6gIyR20EEfVAt+C6638hiApMU3jBuWOsATcN9c0/HhEoyjoKJFgfOTwRgyPG7CJki+kPYLerHmnWP+uEtKvWzvSi1JDke6+OA2w0q04f253ZyMvs8TnO8O2j5Q==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 07 Feb 2022 08:21:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.02.2022 11:18, Roger Pau Monne wrote:
> Make sure softirqs are processed at least once for every call to
> pvh_populate_memory_range. It's likely that none of the calls to
> pvh_populate_memory_range will perform 64 iterations, in which case
> softirqs won't be processed for the whole duration of the p2m
> population.
> 
> In order to force softirqs to be processed at least once for every
> pvh_populate_memory_range call move the increasing of 'i' to be done
> after evaluation, so on the first loop iteration softirqs will
> unconditionally be processed.

Nit: The change still guarantees one invocation only for every
iteration not encountering an error. That's fine from a functional
pov, but doesn't fully match what you claim.

> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -186,7 +186,7 @@ static int __init pvh_populate_memory_range(struct domain 
> *d,
>          start += 1UL << order;
>          nr_pages -= 1UL << order;
>          order_stats[order]++;
> -        if ( (++i % MAP_MAX_ITER) == 0 )
> +        if ( (i++ % MAP_MAX_ITER) == 0 )
>              process_pending_softirqs();
>      }

This way is perhaps easiest, so

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

but I'd like you to consider to avoid doing this on the first
iteration. How about keeping the code here as is, but instead
insert an invocation in the sole caller (and there unconditionally
at the end of every successful loop iteration)?

Furthermore, how about taking the opportunity and deleting the mis-
named and single-use-only MAP_MAX_ITER define?

Jan




 


Rackspace

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