x86: tsc: avoid system instability in hibernation
PATCH RESEND 1/1 x86: tsc: avoid system instability in hibernation
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.
---
Hey,
No changes from first attempt, no pressure on resending. The RESEND tag is just because I missed linux-pm in the first attempt.
BR,
arch/x86/kernel/tsc.c | 29 +++++++++++++++++++++++++++++ include/linux/sched/clock.h | 5 +++++ kernel/sched/clock.c | 4 ++-- 3 files changed, 36 insertions(+), 2 deletions(-)
arch/x86/kernel/tsc.c +29 -0
@@ -13,6 +13,7 @@#include <linux/percpu.h> #include <linux/timex.h> #include <linux/static_key.h> +#include <linux/suspend.h> #include <asm/hpet.h> #include <asm/timer.h>
@@ -1377,3 +1378,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);
include/linux/sched/clock.h +5 -0
@@ -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 );/*
kernel/sched/clock.c +2 -2
@@ -131,7 +131,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;
@@ -228,7 +228,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 ; }
Signature · 1 line
2.18.0
Quoted 3 lines · Eduardo Valentin
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,
Isn't that the actual bug?
Quoted 20 lines
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/stateMessage 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!
Quoted 6 lines
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.
I would rather call it a workaround.
Quoted 53 lines
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.Cc Thomas Gleixner <[email protected]>Cc Ingo Molnar <[email protected]>Cc "H. Peter Anvin" <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Dou Liyang <[email protected]>Cc Len Brown <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Eduardo Valentin <[email protected]>Cc Rajvi Jingar <[email protected]>Cc Pavel Tatashin <[email protected]>Cc Philippe Ombredanne <[email protected]>Cc Kate Stewart <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>---
Hey,
No changes from first attempt, no pressure on resending. The RESEND tag is just because I missed linux-pm in the first attempt.
BR,
arch/x86/kernel/tsc.c | 29 +++++++++++++++++++++++++++++ include/linux/sched/clock.h | 5 +++++ kernel/sched/clock.c | 4 ++-- 3 files changed, 36 insertions(+), 2 deletions(-)arch/x86/kernel/tsc.c +1
-0@@ -13,6 +13,7 @@#include <linux/percpu.h> #include <linux/timex.h> #include <linux/static_key.h> +#include <linux/suspend.h> #include <asm/hpet.h> #include <asm/timer.h> @@ -1377,3 +1378,31 @@ unsigned long calibrate_delay_is_known(void)return 0 ;
arch/x86/kernel/tsc.c unsigned long calibrate_delay_is_known(void) · line 1388
Quoted 10 lines
arch/x86/kernel/tsc.c +8
-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 ;
This is too early IMO. This happens before hibernation starts, even before the image is created.
arch/x86/kernel/tsc.c unsigned long calibrate_delay_is_known(void) · line 1397
Quoted 9 lines
arch/x86/kernel/tsc.c +9
-0+case PM_POST_HIBERNATION : +/* Set back to the default */ +if (!check_tsc_unstable ()) +set_sched_clock_stable (); +break ; + } + +return 0 ; +};
If anything like this is the way to go, which honestly I doubt, I would prefer it to be done in hibernate() in the !in_suspend case.
But why does it only affect hibernation? Do we do something extra for system-wide suspend/resume that is not done for hibernation?
Quoted 27 lines · Rafael J. Wysocki
Quoted 3 lines · Eduardo Valentin
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,
Isn't that the actual bug?
Quoted 20 lines
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/stateMessage 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!
Quoted 8 lines
Quoted 6 lines
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.
I would rather call it a workaround.
ok.
Quoted 59 lines
Quoted 59 lines
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.Cc Thomas Gleixner <[email protected]>Cc Ingo Molnar <[email protected]>Cc "H. Peter Anvin" <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Dou Liyang <[email protected]>Cc Len Brown <[email protected]>Cc "Rafael J. Wysocki" <[email protected]>Cc Eduardo Valentin <[email protected]>Cc Rajvi Jingar <[email protected]>Cc Pavel Tatashin <[email protected]>Cc Philippe Ombredanne <[email protected]>Cc Kate Stewart <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Eduardo Valentin <[email protected]>---
Hey,
No changes from first attempt, no pressure on resending. The RESEND tag is just because I missed linux-pm in the first attempt.
BR,
arch/x86/kernel/tsc.c | 29 +++++++++++++++++++++++++++++ include/linux/sched/clock.h | 5 +++++ kernel/sched/clock.c | 4 ++-- 3 files changed, 36 insertions(+), 2 deletions(-)arch/x86/kernel/tsc.c +4
-0@@ -13,6 +13,7 @@#include <linux/percpu.h> #include <linux/timex.h> #include <linux/static_key.h> +#include <linux/suspend.h> #include <asm/hpet.h> #include <asm/timer.h> @@ -1377,3 +1378,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)
Quoted 8 lines
arch/x86/kernel/tsc.c unsigned long calibrate_delay_is_known(void) · line 1388
Quoted 5 lines
arch/x86/kernel/tsc.c +5
-0+{ +switch (pm_event) { +case PM_HIBERNATION_PREPARE : +clear_sched_clock_stable (); +break ;This is too early IMO. This happens before hibernation starts, even before the image is created.
Yeah, I think, as long as it is marked, it should be fine.
Quoted 14 lines
arch/x86/kernel/tsc.c unsigned long calibrate_delay_is_known(void) · line 1397
Quoted 10 lines
arch/x86/kernel/tsc.c +9
-0+case PM_POST_HIBERNATION : +/* Set back to the default */ +if (!check_tsc_unstable ()) +set_sched_clock_stable (); +break ; + } + +return 0 ; +};If anything like this is the way to go, which honestly I doubt, I would prefer it to be done in
hibernate()in the !in_suspend case.
The problem is more in the unfreeze of tasks..
Quoted 2 lines
But why does it only affect hibernation? Do we do something extra for system-wide suspend/resume that is not done for hibernation?
I don't think we do anything special in hibernation per si. Only thing is the unfreezing of tasks seams to get confused when CPU hog tasks are present.
Quoted 1 line
Signature · 2 lines
All the best, Eduardo Valentin
Peter Zijlstra
maintainerQuoted 3 lines · Eduardo Valentin
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
Which would suggest you're already running with unstable sched clock. Otherwise nobody would care about the scd stuff.
What kind of machine are you running? What does:
dmesg | grep -i tsc
say?
Quoted 8 lines
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.
None of this makes any sense. Either you were already unstable and it should already have worked and them marking it stable is an outright bug, or your sched clock was stable but then your initial diagnosis of lack of scd updates is complete garbage.
Hey Peter,
Quoted 7 lines · Peter Zijlstra
Quoted 3 lines · Eduardo Valentin
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
Which would suggest you're already running with unstable sched clock. Otherwise nobody would care about the scd stuff.
Yes.
Quoted 6 lines
What kind of machine are you running? What does:
dmesg | grep -i tsc
say?
Here:
[ 0.000000] tsc: Fast TSC calibration using PIT [ 0.004005] tsc: Detected 3000.000 MHz processor [ 0.066796] TSC deadline timer enabled [ 3.904269] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b3e459bf4c, max_idle_ns: 440795289890 ns
Quoted 10 lines
Quoted 9 lines
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.
Quoted 5 lines
None of this makes any sense. Either you were already unstable and it should already have worked and them marking it stable is an outright bug, or your sched clock was stable but then your initial diagnosis of lack of scd updates is complete garbage.
I see, or it is just a workaround for the underling issue. I, for sure, see no lockups anymore after forcing the scd updates. The other thing which are not super clear is that this happens during the unfreezing of tasks. If I get a set of cpu hog tasks while unfreezing, I see the system throwing worqueue lockup detectors in hibernation restore.
Quoted 1 line
Signature · 2 lines
All the best, Eduardo Valentin
Quoted 10 lines · Eduardo Valentin
Quoted 7 lines · Peter Zijlstra
Quoted 3 lines · Eduardo Valentin
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
Which would suggest you're already running with unstable sched clock. Otherwise nobody would care about the scd stuff.
Yes.
I doubt that...
Quoted 5 lines
Quoted 5 lines
What kind of machine are you running? What does:
dmesg | grep -i tsc
Quoted 8 lines
Quoted 1 line
say?
Here:
[ 0.000000] tsc: Fast TSC calibration using PIT [ 0.004005] tsc: Detected 3000.000 MHz processor [ 0.066796] TSC deadline timer enabled [ 3.904269] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b3e459bf4c, max_idle_ns: 440795289890 ns
... because if the sched clock would be unstable then you'd have something like 'TSC unstable' in dmesg, which you obviously do not.
'sched_clock: Marking unstable' is the other message which would be emitted.
Quoted 15 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 5 lines
None of this makes any sense. Either you were already unstable and it should already have worked and them marking it stable is an outright bug, or your sched clock was stable but then your initial diagnosis of lack of scd updates is complete garbage.
Quoted 5 lines
I see, or it is just a workaround for the underling issue. I, for sure, see no lockups anymore after forcing the scd updates. The other thing which are not super clear is that this happens during the unfreezing of tasks. If I get a set of cpu hog tasks while unfreezing, I see the system throwing worqueue lockup detectors in hibernation restore.
Yes, it pretty much papers over something else. Can you please provide a full dmesg from boot to failure case?
Another question: Does the system recover after issuing the lockup messages or is it hosed completely?
Thanks,
tglx