Date: Fri, 5 Jun 2015 16:02:24 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: John Stultz <john.stultz@linaro.org>
cc: Jeremiah Mahler <jmmahler@gmail.com>,
        Preeti U Murthy <preeti@linux.vnet.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        Marcelo Tosatti <mtosatti@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume
In-Reply-To: <alpine.DEB.2.11.1506051110040.4155@nanos>
Message-ID: <alpine.DEB.2.11.1506051601560.7723@nanos>
References: <20150604005624.GA1789@hudson.localdomain> <CALAqxLUAXDHimaqA0mqUNcY0inOZGRf92SxSbX8dDMzJUBRvmQ@mail.gmail.com> <alpine.DEB.2.11.1506051110040.4155@nanos>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1680
Lines: 37

On Fri, 5 Jun 2015, Thomas Gleixner wrote:

> On Thu, 4 Jun 2015, 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.
> 
> Duh, yes.
>  
> > 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.
> 
> It's not about copying 24 bytes. It's about touching 3 cache lines for
> nothing. In situations where we run high frequency periodic timers on
> clock monotonic and nothing is going on in the other clock domains,
> which is a pretty common situation, this is measurable in terms of
> cache utilization. I went great length to optimize the cache footprint
> and access patterns and that unconditional update really makes a
> measurable difference.

That said. Can you please send a patch with a proper changelog?

Thanks,

	tglx
--
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/