From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E241BC352A4 for ; Wed, 12 Feb 2020 22:35:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B46E421734 for ; Wed, 12 Feb 2020 22:35:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazon.com header.i=@amazon.com header.b="iatwNokw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728098AbgBLWfz (ORCPT ); Wed, 12 Feb 2020 17:35:55 -0500 Received: from smtp-fw-33001.amazon.com ([207.171.190.10]:20597 "EHLO smtp-fw-33001.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727947AbgBLWfz (ORCPT ); Wed, 12 Feb 2020 17:35:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1581546954; x=1613082954; h=date:from:to:subject:message-id:mime-version; bh=mAb4SIbaoDODH4/U698l6fYXrmrb6YPbZDM+uvQY0QE=; b=iatwNokwJfmqybGRbKGmmuyX4HVWBliDadeXDwfydFKfy7/e8scEqcBo EBgT6mSZGotmLe9gKupcL4xJLwiLGTFBTgTYq/W2dwGJQTBOiJZn/8+qG FonS8bsM0/5uAt9Te1wd1vJfkS5ZjDJUyw0LaUlZKtZEHvYvp46q2IE0j s=; IronPort-SDR: 1TWmY1HVjrLqoQ7uteZMkEOTJhXdjkOW3b8fpdoEoaiYwZhT6a8l//IPpK5Y8YqgCdgDuPuJ93 Y1bbRTNghAjA== X-IronPort-AV: E=Sophos;i="5.70,434,1574121600"; d="scan'208";a="26089661" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1a-807d4a99.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 12 Feb 2020 22:35:52 +0000 Received: from EX13MTAUEB002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-807d4a99.us-east-1.amazon.com (Postfix) with ESMTPS id 8A1EBA1D80; Wed, 12 Feb 2020 22:35:44 +0000 (UTC) Received: from EX13D08UEB001.ant.amazon.com (10.43.60.245) by EX13MTAUEB002.ant.amazon.com (10.43.60.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 12 Feb 2020 22:35:19 +0000 Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by EX13D08UEB001.ant.amazon.com (10.43.60.245) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 12 Feb 2020 22:35:19 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id 15.0.1367.3 via Frontend Transport; Wed, 12 Feb 2020 22:35:19 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 4B461400D1; Wed, 12 Feb 2020 22:35:19 +0000 (UTC) Date: Wed, 12 Feb 2020 22:35:19 +0000 From: Anchal Agarwal To: , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: [RFC PATCH v3 11/12] xen: Update sched clock offset to avoid system instability in hibernation Message-ID: <20200212223519.GA4483@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Save/restore xen_sched_clock_offset in syscore suspend/resume during PM hibernation. Commit '867cefb4cb1012: ("xen: Fix x86 sched_clock() interface for xen")' fixes xen guest time handling during migration. A similar issue is seen during PM hibernation when system runs CPU intensive workload. Post resume pvclock resets the value to 0 however, xen sched_clock_offset is never updated. System instability is seen during resume from hibernation when system is under heavy CPU load. Since xen_sched_clock_offset is not updated, system does not see the monotonic clock value and the scheduler would then think that heavy CPU hog tasks need more time in CPU, causing the system to freeze Signed-off-by: Anchal Agarwal --- Changes Since V2: * New patch to update sched clock offset during hibernation to avoid hungups during resume when running a CPU intensive workload --- arch/x86/xen/suspend.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c index dae0f74f5390..7e5275944810 100644 --- a/arch/x86/xen/suspend.c +++ b/arch/x86/xen/suspend.c @@ -105,6 +105,8 @@ static int xen_syscore_suspend(void) xen_save_steal_clock(cpu); } + xen_save_sched_clock_offset(); + xrfp.domid = DOMID_SELF; xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT; @@ -126,6 +128,12 @@ static void xen_syscore_resume(void) pvclock_resume(); + /* + * Restore xen_sched_clock_offset during resume to maintain + * monotonic clock value + */ + xen_restore_sched_clock_offset(); + /* Nonboot CPUs will be resumed when they're brought up */ xen_restore_steal_clock(smp_processor_id()); -- 2.24.1.AMZN