From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] Date: Fri, 28 Oct 2016 20:58:41 +0200 (CEST) Message-ID: References: <20160531072650.GP4329@intel.com> <20160713145425.GB4329@intel.com> <20160809172057.GZ4329@intel.com> <20161027172852.GE4617@intel.com> <20161027192006.GF4617@intel.com> <20161027203745.GH4617@intel.com> <20161028155603.GI4617@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-621006073-1477681124=:5053" Return-path: In-Reply-To: <20161028155603.GI4617@intel.com> Sender: linux-kernel-owner@vger.kernel.org To: =?ISO-8859-15?Q?Ville_Syrj=E4l=E4?= Cc: Feng Tang , feng.tang@intel.com, "Rafael J. Wysocki" , "Rafael J. Wysocki" , Steven Rostedt , Sebastian Andrzej Siewior , linux-arch@vger.kernel.org, Rik van Riel , "Srivatsa S. Bhat" , Peter Zijlstra , Arjan van de Ven , Rusty Russell , Oleg Nesterov , Tejun Heo , Andrew Morton , Paul McKenney , Linus Torvalds , Paul Turner , Linux Kernel Mailing List , "Zhang, Rui" List-Id: linux-acpi@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-621006073-1477681124=:5053 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 28 Oct 2016, Ville Syrjälä wrote: > On Thu, Oct 27, 2016 at 10:41:18PM +0200, Thomas Gleixner wrote: > > On Thu, 27 Oct 2016, Ville Syrjälä wrote: > > > On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote: > > > > So it would be interesting whether that hunk in resume_broadcast() is > > > > sufficient. > > > > > > So far it looks like the answer is yes. > > > > > > Looks to be about 5 seconds slower than acpi-idle in resuming, but > > > I suppose that's not all that surprising ;) > > > > Well, set it to 1msec then. If that works reliably then we really can do > > that unconditionally. There is no harm in firing a useless timer during > > resume once. > > I narrowed down the required timeout, and looks like 25ms is the > minimum that works. With 24ms I already started to have failures. So > maybe just bump it up by an order of magnitude to 250ms for some > safety margin? Sure, but what puzzles me is that we need a timeout that big. What happens between broadcast_resume() and broadcast_resume() + 25ms? IOW, what is the event/resume function which we need to bridge. We should really try to track than down. You might try to enable function tracing and do a tracing_off() when that 25ms timeout fires. Something like stop_trace = true; in broadcast_resume() and then in the broadcast timer function: if (stop_trace) { stop_trace = false; tracing_off(); } Then when the machine is up read the trace, compress and upload it somewhere or send it in private mail if it's not that big. Thanks, tglx --8323329-621006073-1477681124=:5053-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756730AbcJ1TBs (ORCPT ); Fri, 28 Oct 2016 15:01:48 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:48184 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756557AbcJ1TBq (ORCPT ); Fri, 28 Oct 2016 15:01:46 -0400 Date: Fri, 28 Oct 2016 20:58:41 +0200 (CEST) From: Thomas Gleixner To: =?ISO-8859-15?Q?Ville_Syrj=E4l=E4?= cc: Feng Tang , feng.tang@intel.com, "Rafael J. Wysocki" , "Rafael J. Wysocki" , Steven Rostedt , Sebastian Andrzej Siewior , linux-arch@vger.kernel.org, Rik van Riel , "Srivatsa S. Bhat" , Peter Zijlstra , Arjan van de Ven , Rusty Russell , Oleg Nesterov , Tejun Heo , Andrew Morton , Paul McKenney , Linus Torvalds , Paul Turner , Linux Kernel Mailing List , "Zhang, Rui" , Len Brown , Linux PM , Linux ACPI Subject: Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] In-Reply-To: <20161028155603.GI4617@intel.com> Message-ID: References: <20160531072650.GP4329@intel.com> <20160713145425.GB4329@intel.com> <20160809172057.GZ4329@intel.com> <20161027172852.GE4617@intel.com> <20161027192006.GF4617@intel.com> <20161027203745.GH4617@intel.com> <20161028155603.GI4617@intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-621006073-1477681124=:5053" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-621006073-1477681124=:5053 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Fri, 28 Oct 2016, Ville Syrjälä wrote: > On Thu, Oct 27, 2016 at 10:41:18PM +0200, Thomas Gleixner wrote: > > On Thu, 27 Oct 2016, Ville Syrjälä wrote: > > > On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote: > > > > So it would be interesting whether that hunk in resume_broadcast() is > > > > sufficient. > > > > > > So far it looks like the answer is yes. > > > > > > Looks to be about 5 seconds slower than acpi-idle in resuming, but > > > I suppose that's not all that surprising ;) > > > > Well, set it to 1msec then. If that works reliably then we really can do > > that unconditionally. There is no harm in firing a useless timer during > > resume once. > > I narrowed down the required timeout, and looks like 25ms is the > minimum that works. With 24ms I already started to have failures. So > maybe just bump it up by an order of magnitude to 250ms for some > safety margin? Sure, but what puzzles me is that we need a timeout that big. What happens between broadcast_resume() and broadcast_resume() + 25ms? IOW, what is the event/resume function which we need to bridge. We should really try to track than down. You might try to enable function tracing and do a tracing_off() when that 25ms timeout fires. Something like stop_trace = true; in broadcast_resume() and then in the broadcast timer function: if (stop_trace) { stop_trace = false; tracing_off(); } Then when the machine is up read the trace, compress and upload it somewhere or send it in private mail if it's not that big. Thanks, tglx --8323329-621006073-1477681124=:5053--