Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752516AbbFDA4g (ORCPT ); Wed, 3 Jun 2015 20:56:36 -0400 Received: from mail-qg0-f51.google.com ([209.85.192.51]:33845 "EHLO mail-qg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753131AbbFDA40 (ORCPT ); Wed, 3 Jun 2015 20:56:26 -0400 Date: Wed, 3 Jun 2015 17:56:24 -0700 From: Jeremiah Mahler To: Thomas Gleixner Cc: Preeti U Murthy , Peter Zijlstra , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , John Stultz , linux-kernel@vger.kernel.org Subject: [BUG, bisect] hrtimer: severe lag after suspend & resume Message-ID: <20150604005624.GA1789@hudson.localdomain> Mail-Followup-To: Jeremiah Mahler , Thomas Gleixner , Preeti U Murthy , Peter Zijlstra , Viresh Kumar , Marcelo Tosatti , Frederic Weisbecker , John Stultz , linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 2308 Lines: 51 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(-) -- - Jeremiah Mahler -- 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/