Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932310AbbFDWyj (ORCPT ); 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 MIME-Version: 1.0 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 Content-Type: multipart/mixed; boundary=089e0122e6883dd24c0517b90fb8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4402 Lines: 90 --089e0122e6883dd24c0517b90fb8 Content-Type: text/plain; charset=UTF-8 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 --089e0122e6883dd24c0517b90fb8 Content-Type: text/x-patch; charset=US-ASCII; name="fixup.patch" Content-Disposition: attachment; filename="fixup.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iais4qzk0 ZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgYi9rZXJuZWwvdGltZS90aW1l a2VlcGluZy5jCmluZGV4IDkwZWQ1ZGIuLjUzYmU3OTYgMTAwNjQ0Ci0tLSBhL2tlcm5lbC90aW1l L3RpbWVrZWVwaW5nLmMKKysrIGIva2VybmVsL3RpbWUvdGltZWtlZXBpbmcuYwpAQCAtNTgwLDYg KzU4MCw5IEBAIHN0YXRpYyB2b2lkIHRpbWVrZWVwaW5nX3VwZGF0ZShzdHJ1Y3QgdGltZWtlZXBl ciAqdGssIHVuc2lnbmVkIGludCBhY3Rpb24pCiAJCW50cF9jbGVhcigpOwogCX0KIAorCWlmIChh Y3Rpb24gJiBUS19DTE9DS19XQVNfU0VUKQorCQl0ay0+Y2xvY2tfd2FzX3NldF9zZXErKzsKKwog CXRrX3VwZGF0ZV9rdGltZV9kYXRhKHRrKTsKIAogCXVwZGF0ZV92c3lzY2FsbCh0ayk7CkBAIC01 OTEsOSArNTk0LDYgQEAgc3RhdGljIHZvaWQgdGltZWtlZXBpbmdfdXBkYXRlKHN0cnVjdCB0aW1l a2VlcGVyICp0aywgdW5zaWduZWQgaW50IGFjdGlvbikKIAogCXVwZGF0ZV9mYXN0X3RpbWVrZWVw ZXIoJnRrLT50a3JfbW9ubywgJnRrX2Zhc3RfbW9ubyk7CiAJdXBkYXRlX2Zhc3RfdGltZWtlZXBl cigmdGstPnRrcl9yYXcsICAmdGtfZmFzdF9yYXcpOwotCi0JaWYgKGFjdGlvbiAmIFRLX0NMT0NL X1dBU19TRVQpCi0JCXRrLT5jbG9ja193YXNfc2V0X3NlcSsrOwogfQogCiAvKioK --089e0122e6883dd24c0517b90fb8-- -- 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/