Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422782AbbFEOCe (ORCPT ); Fri, 5 Jun 2015 10:02:34 -0400 Received: from www.linutronix.de ([62.245.132.108]:35567 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422767AbbFEOC3 (ORCPT ); Fri, 5 Jun 2015 10:02:29 -0400 Date: Fri, 5 Jun 2015 16:02:24 +0200 (CEST) From: Thomas Gleixner To: John Stultz cc: Jeremiah Mahler , Preeti U Murthy , Peter Zijlstra , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , lkml , Ingo Molnar Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume In-Reply-To: Message-ID: References: <20150604005624.GA1789@hudson.localdomain> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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 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/