From patchwork Thu Jun 4 22:54:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 49552 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wi0-f198.google.com (mail-wi0-f198.google.com [209.85.212.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id AF51721562 for ; Thu, 4 Jun 2015 22:54:47 +0000 (UTC) Received: by wiam3 with SMTP id m3sf629890wia.3 for ; Thu, 04 Jun 2015 15:54:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:mime-version:in-reply-to:references :date:message-id:subject:from:to:content-type:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe; bh=EO4iwoFhMzsHrcl/nsDRAicnBOsH5vRJSYiSu7G9v3E=; b=jQlHapneFQ/xLVyxKNBqAzXdip/LbhIKrGENBA/PDWPv+56+StsJHyBWx9sUwk7CeU OQg+I4/JD1iw6AuT2zhEoEqLsrsT0IXD8HWZdFm6U4qOYezDHDYAv/aAAmzzR7gUq4u6 vG9yeOMhX6oTdCogtE5VnXhlGewi8V2bbmgqHgfHkVRn+rDmRumZD8uk2+Tl0QURo8DX aXLzRn4dnozFemzSZcejaBWOlPl42sEeJ7NaEE0i9RQRltAZaKuRlwss2skTXWbQhJq/ OLFjw4KHa1T+Q9B+9OSi0LFnF7lf3ifmRdvnwmUw+mDlj5je2UV6lV3gz9sNMFP98+k2 PxQw== X-Gm-Message-State: ALoCoQns/yaefSkiVvhpwnO7biVgehV0oi4LAhm74BZoUzZC8fcQ3kP7l/raceMI+ZgBAGPm+QFq X-Received: by 10.112.161.105 with SMTP id xr9mr351507lbb.20.1433458486960; Thu, 04 Jun 2015 15:54:46 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.36.227 with SMTP id t3ls285542laj.72.gmail; Thu, 04 Jun 2015 15:54:46 -0700 (PDT) X-Received: by 10.112.219.201 with SMTP id pq9mr313482lbc.109.1433458486710; Thu, 04 Jun 2015 15:54:46 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com. [209.85.215.47]) by mx.google.com with ESMTPS id e9si3127890lag.58.2015.06.04.15.54.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 15:54:46 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; Received: by labko7 with SMTP id ko7so42310521lab.2 for ; Thu, 04 Jun 2015 15:54:46 -0700 (PDT) X-Received: by 10.152.44.166 with SMTP id f6mr367634lam.86.1433458486607; Thu, 04 Jun 2015 15:54:46 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.108.230 with SMTP id hn6csp948320lbb; Thu, 4 Jun 2015 15:54:45 -0700 (PDT) X-Received: by 10.70.49.43 with SMTP id r11mr522557pdn.91.1433458484389; Thu, 04 Jun 2015 15:54:44 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id tb2si7938044pac.63.2015.06.04.15.54.43; Thu, 04 Jun 2015 15:54:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932311AbbFDWyj (ORCPT + 28 others); Thu, 4 Jun 2015 18:54:39 -0400 Received: from mail-ig0-f176.google.com ([209.85.213.176]:36255 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752616AbbFDWyg (ORCPT ); Thu, 4 Jun 2015 18:54:36 -0400 Received: by igbpi8 with SMTP id pi8so2593336igb.1 for ; Thu, 04 Jun 2015 15:54:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.78.170 with SMTP id c10mr8464973igx.0.1433458475588; Thu, 04 Jun 2015 15:54:35 -0700 (PDT) Received: by 10.50.130.148 with HTTP; Thu, 4 Jun 2015 15:54:35 -0700 (PDT) In-Reply-To: <20150604005624.GA1789@hudson.localdomain> References: <20150604005624.GA1789@hudson.localdomain> Date: Thu, 4 Jun 2015 15:54:35 -0700 Message-ID: Subject: Re: [BUG, bisect] hrtimer: severe lag after suspend & resume From: John Stultz To: Jeremiah Mahler , Thomas Gleixner , Preeti U Murthy , Peter Zijlstra , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , John Stultz , lkml , Ingo Molnar Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.47 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Wed, Jun 3, 2015 at 5:56 PM, Jeremiah Mahler wrote: > all, > > After a fresh boot, the Chrome web browser behaves normally. Pages > load quickly and scroll fast. Even image heavy sites such as > images.google.com work fine. However, after a suspend and resume > cycle, Chrome becomes very slow. Pages take ten seconds or more to > load. The scroll bars and buttons are almost completely > unresponsive. Interestingly, I can run Firefox on the same sites > and it has no issue whatsoever. > > I have bisected the kernel and found that the following commit > introduced the bug. It is present in the latest linux-next (20150602). > > From 868a3e915f7f5eba8f8cb4f7da2276760807c51c Mon Sep 17 00:00:00 2001 > From: Thomas Gleixner > Date: Tue, 14 Apr 2015 21:08:37 +0000 > Subject: [PATCH] hrtimer: Make offset update smarter > > On every tick/hrtimer interrupt we update the offset variables of the > clock bases. That's silly because these offsets change very seldom. > > Add a sequence counter to the time keeping code which keeps track of > the offset updates (clock_was_set()). Have a sequence cache in the > hrtimer cpu bases to evaluate whether the offsets must be updated or > not. This allows us later to avoid pointless cacheline pollution. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Preeti U Murthy > Acked-by: Peter Zijlstra > Cc: Viresh Kumar > Cc: Marcelo Tosatti > Cc: Frederic Weisbecker > Cc: John Stultz > Link: http://lkml.kernel.org/r/20150414203501.132820245@linutronix.de > Signed-off-by: Thomas Gleixner > Cc: John Stultz > --- > include/linux/hrtimer.h | 4 ++-- > include/linux/timekeeper_internal.h | 2 ++ > kernel/time/hrtimer.c | 3 ++- > kernel/time/timekeeping.c | 23 ++++++++++++++++------- > kernel/time/timekeeping.h | 7 ++++--- > 5 files changed, 26 insertions(+), 13 deletions(-) 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++; } /**