| Message ID | 20190402053457.24912-5-jgross@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xen: simplify suspend/resume handling | expand |
>>> On 02.04.19 at 07:34, <jgross@suse.com> wrote: > Instead of freeing percpu areas during suspend and allocating them > again when resuming keep them. Only free an area in case a cpu didn't > come up again when resuming. > > It should be noted that there is a potential change in behaviour as > the percpu areas are no longer zeroed out during suspend/resume. While > I have checked the called cpu notifier hooks to cope with that there > might be some well hidden dependency on the previous behaviour. OTOH > a component not registering itself for cpu down/up and expecting to > see a zeroed percpu variable after suspend/resume is kind of broken > already. And the opposite case, where a component is not registered > to be called for cpu down/up and is not expecting a percpu variable > suddenly to be zero due to suspend/resume is much more probable, > especially as the suspend/resume functionality seems not to be tested > that often. > > Signed-off-by: Juergen Gross <jgross@suse.com> > Reviewed-by: Dario Faggioli <dfaggioli@suse.com> Acked-by: Jan Beulich <jbeulich@suse.com> Wasn't there a request though to do the same on Arm? Even if right now Arm doesn't support suspend/resume out of the box, I think it would be better if such relatively generic adjustments were done in lock step. Jan
On 02/04/2019 13:57, Jan Beulich wrote: >>>> On 02.04.19 at 07:34, <jgross@suse.com> wrote: >> Instead of freeing percpu areas during suspend and allocating them >> again when resuming keep them. Only free an area in case a cpu didn't >> come up again when resuming. >> >> It should be noted that there is a potential change in behaviour as >> the percpu areas are no longer zeroed out during suspend/resume. While >> I have checked the called cpu notifier hooks to cope with that there >> might be some well hidden dependency on the previous behaviour. OTOH >> a component not registering itself for cpu down/up and expecting to >> see a zeroed percpu variable after suspend/resume is kind of broken >> already. And the opposite case, where a component is not registered >> to be called for cpu down/up and is not expecting a percpu variable >> suddenly to be zero due to suspend/resume is much more probable, >> especially as the suspend/resume functionality seems not to be tested >> that often. >> >> Signed-off-by: Juergen Gross <jgross@suse.com> >> Reviewed-by: Dario Faggioli <dfaggioli@suse.com> > > Acked-by: Jan Beulich <jbeulich@suse.com> > > Wasn't there a request though to do the same on Arm? Even if > right now Arm doesn't support suspend/resume out of the box, > I think it would be better if such relatively generic adjustments > were done in lock step. Julien asked to include that in the ARM suspend/resume series. Juergen
diff --git a/xen/arch/x86/percpu.c b/xen/arch/x86/percpu.c index 8be4ebddf4..5ea14b6ec3 100644 --- a/xen/arch/x86/percpu.c +++ b/xen/arch/x86/percpu.c @@ -76,7 +76,8 @@ static int cpu_percpu_callback( break; case CPU_UP_CANCELED: case CPU_DEAD: - if ( !park_offline_cpus ) + case CPU_RESUME_FAILED: + if ( !park_offline_cpus && system_state != SYS_STATE_suspend ) free_percpu_area(cpu); break; case CPU_REMOVE: