Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1158895

Re: [BUG, bisect] hrtimer: severe lag after suspend & resume

From Jeremiah Mahler <jmmahler@gmail.com>
Newsgroups linux.kernel
Subject Re: [BUG, bisect] hrtimer: severe lag after suspend & resume
Date 2015-06-05 02:10 +0200
Message-ID <pxNmX-8sC-35@gated-at.bofh.it> (permalink)
References <pxrFL-1a9-7@gated-at.bofh.it> <pxMhb-6Fj-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


John,

On Thu, Jun 04, 2015 at 03:54:35PM -0700, John Stultz wrote:
> On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler <jmmahler@gmail.com> wrote:
[...]
> 
> 
> So I suspect the problem is the change to clock_was_set_seq in
> timekeeping_update is done prior to mirroring the time state to the
> shadow-timekeeper. Thus the next time we do update_wall_time() the
> updated sequence is overwritten by whats in the shadow copy. The
> attached patch moving the modification up seems to avoid the issue for
> me.
> 
> Thomas:  Looking at the problematic change, I'm not a big fan of it.
> Caching timekeeping state here in the hrtimer code has been a source
> of bugs in the past, and I'm not sure I see how avoiding copying
> 24bytes is that big of a win. Especially since it adds more state to
> the timekeeper and hrtimer base that we have to read and mange.
> Personally I'd prefer a revert to my fix.
> 
> thanks
> -john

> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 90ed5db..53be796 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -580,6 +580,9 @@ static void timekeeping_update(struct timekeeper *tk, unsigned int action)
>  		ntp_clear();
>  	}
>  
> +	if (action & TK_CLOCK_WAS_SET)
> +		tk->clock_was_set_seq++;
> +
>  	tk_update_ktime_data(tk);
>  
>  	update_vsyscall(tk);
> @@ -591,9 +594,6 @@ static void timekeeping_update(struct timekeeper *tk, unsigned int action)
>  
>  	update_fast_timekeeper(&tk->tkr_mono, &tk_fast_mono);
>  	update_fast_timekeeper(&tk->tkr_raw,  &tk_fast_raw);
> -
> -	if (action & TK_CLOCK_WAS_SET)
> -		tk->clock_was_set_seq++;
>  }
>  
>  /**

That patch fixes the problem for me.

Thanks John.

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

[BUG, bisect] hrtimer: severe lag after suspend & resume Jeremiah Mahler <jmmahler@gmail.com> - 2015-06-04 03:00 +0200
  Re: [BUG, bisect] hrtimer: severe lag after suspend & resume Thomas Gleixner <tglx@linutronix.de> - 2015-06-04 13:30 +0200
  Re: [BUG, bisect] hrtimer: severe lag after suspend & resume Jeremiah Mahler <jmmahler@gmail.com> - 2015-06-05 02:10 +0200

csiph-web