From patchwork Tue Sep 6 12:41:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?SsO8cmdlbiBHcm/Dnw==?= X-Patchwork-Id: 12968225 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0DD7BC38145 for ; Tue, 6 Sep 2022 21:49:39 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.400308.642011 (Exim 4.92) (envelope-from ) id 1oVgRl-0005e5-RE; Tue, 06 Sep 2022 21:49:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 400308.642011; Tue, 06 Sep 2022 21:49:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oVgRl-0005dr-ND; Tue, 06 Sep 2022 21:49:29 +0000 Received: by outflank-mailman (input) for mailman id 400308; Tue, 06 Sep 2022 21:49:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oVgIS-0000Cs-HU for xen-devel@lists.xenproject.org; Tue, 06 Sep 2022 21:39:52 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4020852e-2de1-11ed-af93-0125da4c0113; Tue, 06 Sep 2022 14:41:38 +0200 (CEST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3E83D338B0; Tue, 6 Sep 2022 12:41:38 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F1E6F13A7A; Tue, 6 Sep 2022 12:41:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id wFyTOQFAF2NiSQAAMHmgww (envelope-from ); Tue, 06 Sep 2022 12:41:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4020852e-2de1-11ed-af93-0125da4c0113 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1662468098; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=8y5B8SeVYhFEQ1i+eFOmTPV0zpAN2fLm9xCblFTGrrY=; b=WFFiWAmKMwR0GYGaGXHvkDhG/1Dz1fNnkG4tbPLcc1xbEwsY0clI9tciugJ147AZL/zfkE KLAniDghG6hgg4kCrLoKZhD/FH+QUoPQ5dHw+HCM3JBg2uOLfC4f0qzB/7OhXHbZipdzvB m8Yp7fnvvHIjhFUSdXgqb+hOOFRnH3Y= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu , =?utf-8?q?Marek_Marczykowski-G=C3=B3recki?= Subject: [PATCH] xen/timer: don't migrate timers away from cpus during suspend Date: Tue, 6 Sep 2022 14:41:35 +0200 Message-Id: <20220906124135.12998-1-jgross@suse.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 During a suspend/resume cycle timers on all cpus but cpu 0 will be migrated to cpu 0, as the other cpus are taken down. This is problematic in case such a timer is related to a specific vcpu, as the vcpus are not migrated to another cpu during suspend (migrating them would break cpupools and core scheduling). In order to avoid the problems just try to keep the timers on their cpus. Only migrate them away in case resume failed. Doing so isn't problematic, as any vcpu on a cpu not coming back to life would be migrated away, too. Signed-off-by: Juergen Gross Tested-by: Marek Marczykowski-Górecki --- xen/common/timer.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/xen/common/timer.c b/xen/common/timer.c index 9b5016d5ed..6b5473e5f1 100644 --- a/xen/common/timer.c +++ b/xen/common/timer.c @@ -637,6 +637,13 @@ static void free_percpu_timers(unsigned int cpu) ASSERT(ts->heap == dummy_heap); } +static void deinit_timers(unsigned int cpu) +{ + migrate_timers_from_cpu(cpu); + if ( !park_offline_cpus ) + free_percpu_timers(cpu); +} + static int cf_check cpu_callback( struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -655,13 +662,14 @@ static int cf_check cpu_callback( } break; - case CPU_UP_CANCELED: case CPU_DEAD: - case CPU_RESUME_FAILED: - migrate_timers_from_cpu(cpu); + if ( system_state != SYS_STATE_suspend ) + deinit_timers(cpu); + break; - if ( !park_offline_cpus && system_state != SYS_STATE_suspend ) - free_percpu_timers(cpu); + case CPU_UP_CANCELED: + case CPU_RESUME_FAILED: + deinit_timers(cpu); break; case CPU_REMOVE: