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

Re: [PATCH] xen/smp: Speed up on_selected_cpus()


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 7 Feb 2022 09:11:19 +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=XywlAjTsXDZgrpXx3Ss1iRAl8VekY6dFKCueH/IrcNY=; b=cZy02JQqoTGxkCGEphKC2x/rU71Sl+kRCfkFgBKUGOaUdLWA6Aa+bf3HuNWby86gBCSLW7LWO7FXV7zyeBkOngtYi2MHm+i5pzt0Y0ZLgaNI4CZToEkEm61eKNvBsTB8rF6Q5eJbSUCBbIHvZcKXpLSBy6t5MVpaOR5NczI3HMYU5VDMHQ/AAB+lTp3YQAleohpGZYKwWawaPyqO1qeK8oPcgyfnCdIxZ8rnJVSE3FWjgKH1PJqp2tRW+ypFiKDFPlS4HfFjHFsWDwtCRk5lSFqXbjcRTtda1/iQeRYvr3fh6QIgxT8uz2JwAtati0Se3Nb3JGBzip0r1XlcPXRnPQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MuYdGtPVsURcoc2G9nd9C5X77zGcucfS7M+vFoz/cuxzVzKthkCwfSVURC5xqvm8wa+M4mSyfhSOuLIvxEg7I1uoLgIlfk8emvFMcZDlVXeqpjb07vcoy8lfMwfJOvepYk+Q6NoDcmIGGuFYYroZJGS1Gt1uDJVWuvWjFRIF+P5FK095UHjO3Vm0xIuvDJgpCpdT0S3yq5LUIywxbjpULOqNZGNiKxfL50yGeiUFvh4wVPXBtGA2SslUQQC5pHXZZ9IgvliYUrV4ox0Hr10AECtURIVdvXFxExzldezCxo3pDj6iyekSoN0irA60H3uiojUzV6NlUogyXzHN0hdHRg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 07 Feb 2022 08:11:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.02.2022 21:31, Andrew Cooper wrote:
> cpumask_weight() is a horribly expensive way to find if no bits are set, made
> worse by the fact that the calculation is performed with the global call_lock
> held.
> 
> Switch to using cpumask_empty() instead, which will short circuit as soon as
> it find any set bit in the cpumask.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

May I suggest to drop "horribly"? How expensive one is compared to the other
depends on the number of CPUs actually enumerated in the system. (And of
course I still have that conversion to POPCNT alternatives patching pending,
where Roger did ask for some re-work in reply to v2, but where it has
remained unclear whether investing time into that wouldn't be in vein,
considering some of your replies on v1. Thus would have further shrunk the
difference, without me meaning to say the change here isn't a good one.)

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan




 


Rackspace

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