Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754493AbbFEKHQ (ORCPT ); Fri, 5 Jun 2015 06:07:16 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35830 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbbFEKHN (ORCPT ); Fri, 5 Jun 2015 06:07:13 -0400 Date: Fri, 5 Jun 2015 12:07:07 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: John Stultz , Jeremiah Mahler , Preeti U Murthy , Peter Zijlstra , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , lkml Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume Message-ID: <20150605100707.GB8995@gmail.com> References: <20150604005624.GA1789@hudson.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1845 Lines: 41 * 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. [...] It's not just about 'touching': it's about _dirtying_ cachelines from a globally executed function (timekeeping), which is then accessed by per-CPU functionality (hrtimers). That makes it far more expensive, it has similar scalability limiting effects as a global lock - while if we do it smart it can perform as essentially lockless code in most cases. Thanks, Ingo -- 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/