[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150605000142.GA1761@hudson.localdomain>
Date: Thu, 4 Jun 2015 17:01:42 -0700
From: Jeremiah Mahler <jmmahler@...il.com>
To: John Stultz <john.stultz@...aro.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume
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@...il.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists