Re: [Xen-devel] [PATCH 1/4] hrtimers: provide a hrtimers_late_resume() call

[Thomas Gleixner <tglx@xxxxxxxxxxxxx>]

On Thu, 20 Jun 2013, David Vrabel wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
> 
> Xen suspends (and resumes) without disabling non-boot CPUs as doing so
> adds considerable delay to live migrations.  A 4 VCPU guest had more
> than 200 ms of additional downtime if disable_nonboot_cpus() was
> called prior to suspending.
> 
> As a consequence, only high resolution timers on the current CPU are
> retriggered when resuming.  The Xen resume path worked around this
> with a call to clock_was_set() to retrigger timers on all the CPUs.
> 
> A subsequent change will make clock_was_set() internal to hrtimers so
> add an new call (hrtimers_late_resume()) to do the same job.
> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> ---
>  drivers/xen/manage.c    |    8 ++++++--
>  include/linux/hrtimer.h |    1 +
>  kernel/hrtimer.c        |    9 +++++++++
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index 412b96c..75bc2d5 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -166,8 +166,12 @@ out_resume:
>  
>       dpm_resume_end(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
>  
> -     /* Make sure timer events get retriggered on all CPUs */
> -     clock_was_set();
> +     /*
> +      * syscore_resume() ends up calling hrtimer_resume() but this
> +      * only retriggers timer events on the current CPU.  We need
> +      * to retrigger the events on all the other CPUS.
> +      */
> +     hrtimers_late_resume();

This is the completely wrong approach. If an architecture does not
shut down the non boot cpus on suspend, then this wants to be handled
in the core code and not in some random arch specific driver.

Thanks,

        tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel