Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1158895
| 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 |
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
[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