From patchwork Wed Aug 17 08:51:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerald Yang X-Patchwork-Id: 1667162 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=BQ3n1Xxg; dkim-atps=neutral Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4M71y63WJ1z1ygF for ; Wed, 17 Aug 2022 18:53:18 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1oOEnU-0002Q9-FW; Wed, 17 Aug 2022 08:53:08 +0000 Received: from smtp-relay-internal-1.internal ([10.131.114.114] helo=smtp-relay-internal-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1oOEmh-0000cA-5Z for kernel-team@lists.ubuntu.com; Wed, 17 Aug 2022 08:52:19 +0000 Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 4C80F3F46B for ; Wed, 17 Aug 2022 08:52:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1660726337; bh=A4l8gW4qXp/DhvLcbtj81P0LtVTzTJGJYt3b3DjRwJ0=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=BQ3n1XxgptcxSzrn6qLE/mbLW0uL00y/Q/3Itv3/wvU2VZB09YnqfROcIs7vUdQWu 8eiQjoq3/BX3717pfAi6pB6fN8REiQkegqLHEHfV0QdIRAXQd5eCXKh89q/eJn4htX WoWaTFOysnTFpQFNcJE+O8jrGw5eT81B5LAQAScNOyk5zbaLtHh5UZ429Pxt94TjUV L9KlaLVjk3Hkhgw7be1JYE7ZDfTp7PMBeTdaT+gwDILTJaYghjCMdRhFixlM3Y7DSz d90MhhvgNHEQABApfrqyJnWKAfhxrNZHkf/8OYkybdsiGbHpdUpiznkJc/lNezJR3T I7/E+GXmGMXiw== Received: by mail-pg1-f197.google.com with SMTP id f128-20020a636a86000000b004291bf13aa8so3308255pgc.18 for ; Wed, 17 Aug 2022 01:52:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc; bh=A4l8gW4qXp/DhvLcbtj81P0LtVTzTJGJYt3b3DjRwJ0=; b=t0FnqnPoGgw11ULvRFQWn+8DcOFVBOwxsIXw+Z/xNeRv+HkOmc/VYhTr+GXTOVc93G LwG3QIG4gHLicAD+4a8q06+lNQnrmwGulhtY4UIfeY3iSU8vIAKEZ7d7JxTwL5hf4pLA +G5x7kRwlVHfeoN7+mFlu760IatrAU4woQia8Jcm5BbV85BWAseqjSXXy1qiOJWP/Idg arsRNZ0UKEBfscM2zb/0SiTGRtlFTdPlFGq3pYWkdPVxvtzQ8yaRcibVAwXIZLfzKX2E 5fsUzLFi0HfM08c1x8MBuBcHCf7yiVWB5tLowcj+IB/TPVEY7jlp9pN6XeNWQDQyDfO0 sW+Q== X-Gm-Message-State: ACgBeo2oatp82fL1R2YjIQW/H3uN76KGBZJnLyZs1KGZhcltSHxqIhbe PfSv1fHNPJ3/ggkeESy/U7CaP/TD/gBR53Kym2DBTnTXsjBRlfAjUlOMnUeoqslNC6lYDWN9LHN ksmqNvUD/2SEb/YmmKSqj3Z4my9DsfeHzVQ842rS1iw== X-Received: by 2002:a17:90b:4b8e:b0:1f5:49bd:8b0e with SMTP id lr14-20020a17090b4b8e00b001f549bd8b0emr2724315pjb.86.1660726335762; Wed, 17 Aug 2022 01:52:15 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Z/8NpUuVs1YQbDcU6JlYevSDXoGtq+d+FhlukBW8epx+A4NVH8Mwv4bYm1WxY5ILwq7el7g== X-Received: by 2002:a17:90b:4b8e:b0:1f5:49bd:8b0e with SMTP id lr14-20020a17090b4b8e00b001f549bd8b0emr2724294pjb.86.1660726335351; Wed, 17 Aug 2022 01:52:15 -0700 (PDT) Received: from localhost.localdomain (220-135-31-21.hinet-ip.hinet.net. [220.135.31.21]) by smtp.gmail.com with ESMTPSA id s90-20020a17090a69e300b001f522180d46sm1001033pjj.8.2022.08.17.01.52.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 01:52:14 -0700 (PDT) From: Gerald Yang To: kernel-team@lists.ubuntu.com Subject: [SRU][jammy/linux-aws][PATCH 15/20] UBUNTU: SAUCE: x86: tsc: avoid system instability in hibernation Date: Wed, 17 Aug 2022 16:51:44 +0800 Message-Id: <20220817085150.2078055-19-gerald.yang@canonical.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220817085150.2078055-1-gerald.yang@canonical.com> References: <20220817085150.2078055-1-gerald.yang@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Eduardo Valentin BugLink: https://bugs.launchpad.net/bugs/1968062 System instability are seen during resume from hibernation when system is under heavy CPU load. This is due to the lack of update of sched clock data, and the scheduler would then think that heavy CPU hog tasks need more time in CPU, causing the system to freeze during the unfreezing of tasks. For example, threaded irqs, and kernel processes servicing network interface may be delayed for several tens of seconds, causing the system to be unreachable. Situation like this can be reported by using lockup detectors such as workqueue lockup detectors: [root@ip-172-31-67-114 ec2-user]# echo disk > /sys/power/state Message from syslogd@ip-172-31-67-114 at May 7 18:23:21 ... kernel:BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 57s! Message from syslogd@ip-172-31-67-114 at May 7 18:23:21 ... kernel:BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 57s! Message from syslogd@ip-172-31-67-114 at May 7 18:23:21 ... kernel:BUG: workqueue lockup - pool cpus=3 node=0 flags=0x1 nice=0 stuck for 57s! Message from syslogd@ip-172-31-67-114 at May 7 18:29:06 ... kernel:BUG: workqueue lockup - pool cpus=3 node=0 flags=0x1 nice=0 stuck for 403s! The fix for this situation is to mark the sched clock as unstable as early as possible in the resume path, leaving it unstable for the duration of the resume process. This will force the scheduler to attempt to align the sched clock across CPUs using the delta with time of day, updating sched clock data. In a post hibernation event, we can then mark the sched clock as stable again, avoiding unnecessary syncs with time of day on systems in which TSC is reliable. Reviewed-by: Erik Quanstrom Reviewed-by: Frank van der Linden Reviewed-by: Balbir Singh Reviewed-by: Munehisa Kamata Tested-by: Anchal Agarwal Signed-off-by: Eduardo Valentin CR: https://cr.amazon.com/r/8440112/ (cherry picked from commit 885c53db2a97468e0e9af8b4a4b034034f9c182b amazon-5.15.y/mainline) Signed-off-by: Gerald Yang Signed-off-by: Matthew Ruffell --- arch/x86/kernel/tsc.c | 29 +++++++++++++++++++++++++++++ include/linux/sched/clock.h | 5 +++++ kernel/sched/clock.c | 4 ++-- 3 files changed, 36 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index a698196377be..597b35ae7197 100644 --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -1575,3 +1576,31 @@ unsigned long calibrate_delay_is_known(void) return 0; } #endif + +static int tsc_pm_notifier(struct notifier_block *notifier, + unsigned long pm_event, void *unused) +{ + switch (pm_event) { + case PM_HIBERNATION_PREPARE: + clear_sched_clock_stable(); + break; + case PM_POST_HIBERNATION: + /* Set back to the default */ + if (!check_tsc_unstable()) + set_sched_clock_stable(); + break; + } + + return 0; +}; + +static struct notifier_block tsc_pm_notifier_block = { + .notifier_call = tsc_pm_notifier, +}; + +static int tsc_setup_pm_notifier(void) +{ + return register_pm_notifier(&tsc_pm_notifier_block); +} + +subsys_initcall(tsc_setup_pm_notifier); diff --git a/include/linux/sched/clock.h b/include/linux/sched/clock.h index 867d588314e0..902654ac5f7e 100644 --- a/include/linux/sched/clock.h +++ b/include/linux/sched/clock.h @@ -32,6 +32,10 @@ static inline void clear_sched_clock_stable(void) { } +static inline void set_sched_clock_stable(void) +{ +} + static inline void sched_clock_idle_sleep_event(void) { } @@ -51,6 +55,7 @@ static inline u64 local_clock(void) } #else extern int sched_clock_stable(void); +extern void set_sched_clock_stable(void); extern void clear_sched_clock_stable(void); /* diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c index c2b2859ddd82..98003d1e8f5a 100644 --- a/kernel/sched/clock.c +++ b/kernel/sched/clock.c @@ -116,7 +116,7 @@ static void __scd_stamp(struct sched_clock_data *scd) scd->tick_raw = sched_clock(); } -static void __set_sched_clock_stable(void) +void set_sched_clock_stable(void) { struct sched_clock_data *scd; @@ -236,7 +236,7 @@ static int __init sched_clock_init_late(void) smp_mb(); /* matches {set,clear}_sched_clock_stable() */ if (__sched_clock_stable_early) - __set_sched_clock_stable(); + set_sched_clock_stable(); return 0; }