From: "Ville Syrjälä" <ville.syrjala@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de> Cc: Feng Tang <feng.79.tang@gmail.com>, feng.tang@intel.com, "Rafael J. Wysocki" <rafael@kernel.org>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Steven Rostedt <rostedt@goodmis.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, linux-arch@vger.kernel.org, Rik van Riel <riel@redhat.com>, "Srivatsa S. Bhat" <srivatsa@mit.edu>, Peter Zijlstra <peterz@infradead.org>, Arjan van de Ven <arjan@linux.intel.com>, Rusty Russell <rusty@rustcorp.com.au>, Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Paul McKenney <paulmck@linux.vnet.ibm.com>, Linus Torvalds <torvalds@linux-foundation.org>, Paul Turner <pjt@google.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Zhang, Rui" <rui.zhang@intel> Subject: Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] Date: Thu, 27 Oct 2016 23:37:45 +0300 [thread overview] Message-ID: <20161027203745.GH4617@intel.com> (raw) In-Reply-To: <alpine.DEB.2.20.1610272122510.4913@nanos> On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote: > On Thu, 27 Oct 2016, Ville Syrjälä wrote: > > On Thu, Oct 27, 2016 at 08:48:57PM +0200, Thomas Gleixner wrote: > > > What that old patch did, was: > > > > > > 1) Make sure that the broadcast device is actually armed at resume. > > > > > > That might cause the HPET to resume proper. > > > > > > 2) Force a max. 3 seconds rearm when the targeted expiry time is > than 10 > > > seconds > > > > > > That might make sure that lower C-States are never entered. > > > > Doh. I lost the other hunk somewhere. Let's try that again... And indeed > > with the other hunk in tow the machine would appear to resume properly. > > 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 ;) > > > > What's the lowest C-State with acpi-idle and what's the lowest one with > > > intel_idle? > > > > acpi_idle > > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x30 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/power:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/residency:200 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/time:5677316 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:5920 > > > > intel_idle: > > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:MWAIT 0x30 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C4-ATM > > /sys/devices/system/cpu/cpu0/cpuidle/state3/power:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/residency:400 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/time:7146705 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:6826 > > Does the machine work, when you limit intel idle to C3, which would then > match acpi idle ? I'm pretty sure I had tested all of these, but I just double checked to make sure. There's no C3 with intel_idle so I limited to C2, but that did not help. Isn't it possible that ACPI C3 is in fact C4? I thought ACPI C-states are always numbered non-sparsely, and in this case ACPI C3 could be anything from C3 to C11 (if the processor actually supported such states obviously). Actually now that I look at the descriptions for the states in sysfs, it says "MWAIT 0x30" for state3 on both drivers, which I presume means it's in fact C4 for both. -- Ville Syrjälä Intel OTC
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de> Cc: Feng Tang <feng.79.tang@gmail.com>, feng.tang@intel.com, "Rafael J. Wysocki" <rafael@kernel.org>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Steven Rostedt <rostedt@goodmis.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, linux-arch@vger.kernel.org, Rik van Riel <riel@redhat.com>, "Srivatsa S. Bhat" <srivatsa@mit.edu>, Peter Zijlstra <peterz@infradead.org>, Arjan van de Ven <arjan@linux.intel.com>, Rusty Russell <rusty@rustcorp.com.au>, Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Paul McKenney <paulmck@linux.vnet.ibm.com>, Linus Torvalds <torvalds@linux-foundation.org>, Paul Turner <pjt@google.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Zhang, Rui" <rui.zhang@intel.com>, Len Brown <len.brown@intel.com>, Linux PM <linux-pm@vger.kernel.org>, Linux ACPI <linux-acpi@vger.kernel.org> Subject: Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] Date: Thu, 27 Oct 2016 23:37:45 +0300 [thread overview] Message-ID: <20161027203745.GH4617@intel.com> (raw) In-Reply-To: <alpine.DEB.2.20.1610272122510.4913@nanos> On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote: > On Thu, 27 Oct 2016, Ville Syrjälä wrote: > > On Thu, Oct 27, 2016 at 08:48:57PM +0200, Thomas Gleixner wrote: > > > What that old patch did, was: > > > > > > 1) Make sure that the broadcast device is actually armed at resume. > > > > > > That might cause the HPET to resume proper. > > > > > > 2) Force a max. 3 seconds rearm when the targeted expiry time is > than 10 > > > seconds > > > > > > That might make sure that lower C-States are never entered. > > > > Doh. I lost the other hunk somewhere. Let's try that again... And indeed > > with the other hunk in tow the machine would appear to resume properly. > > 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 ;) > > > > What's the lowest C-State with acpi-idle and what's the lowest one with > > > intel_idle? > > > > acpi_idle > > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x30 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/power:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/residency:200 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/time:5677316 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:5920 > > > > intel_idle: > > /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:MWAIT 0x30 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:100 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C4-ATM > > /sys/devices/system/cpu/cpu0/cpuidle/state3/power:0 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/residency:400 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/time:7146705 > > /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:6826 > > Does the machine work, when you limit intel idle to C3, which would then > match acpi idle ? I'm pretty sure I had tested all of these, but I just double checked to make sure. There's no C3 with intel_idle so I limited to C2, but that did not help. Isn't it possible that ACPI C3 is in fact C4? I thought ACPI C-states are always numbered non-sparsely, and in this case ACPI C3 could be anything from C3 to C11 (if the processor actually supported such states obviously). Actually now that I look at the descriptions for the states in sysfs, it says "MWAIT 0x30" for state3 on both drivers, which I presume means it's in fact C4 for both. -- Ville Syrjälä Intel OTC
next prev parent reply other threads:[~2016-10-27 20:37 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-11 10:19 S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] Ville Syrjälä 2016-05-11 12:11 ` Sebastian Andrzej Siewior 2016-05-11 12:21 ` Ville Syrjälä 2016-05-11 12:24 ` Sebastian Andrzej Siewior 2016-05-11 12:41 ` Ville Syrjälä 2016-05-11 12:44 ` Steven Rostedt 2016-05-11 13:34 ` Ville Syrjälä 2016-05-16 19:39 ` Ville Syrjälä 2016-05-17 23:14 ` Rafael J. Wysocki 2016-05-18 7:24 ` Ville Syrjälä 2016-05-26 18:32 ` Ville Syrjälä 2016-05-30 20:43 ` Rafael J. Wysocki 2016-05-31 7:26 ` Ville Syrjälä 2016-05-31 7:26 ` Ville Syrjälä 2016-07-13 14:54 ` Ville Syrjälä 2016-07-13 14:54 ` Ville Syrjälä 2016-07-14 8:29 ` Feng Tang 2016-07-14 8:29 ` Feng Tang 2016-08-09 17:20 ` Ville Syrjälä 2016-08-09 17:20 ` Ville Syrjälä 2016-10-27 17:28 ` Ville Syrjälä 2016-10-27 17:28 ` Ville Syrjälä 2016-10-27 18:48 ` Thomas Gleixner 2016-10-27 18:48 ` Thomas Gleixner 2016-10-27 19:20 ` Ville Syrjälä 2016-10-27 19:20 ` Ville Syrjälä 2016-10-27 19:25 ` Thomas Gleixner 2016-10-27 19:25 ` Thomas Gleixner 2016-10-27 20:37 ` Ville Syrjälä [this message] 2016-10-27 20:37 ` Ville Syrjälä 2016-10-27 20:41 ` Thomas Gleixner 2016-10-27 20:41 ` Thomas Gleixner 2016-10-28 15:56 ` Ville Syrjälä 2016-10-28 15:56 ` Ville Syrjälä 2016-10-28 18:58 ` Thomas Gleixner 2016-10-28 18:58 ` Thomas Gleixner 2016-11-01 20:47 ` Ville Syrjälä 2016-11-01 20:47 ` Ville Syrjälä 2016-11-07 11:49 ` Ville Syrjälä 2016-11-07 11:49 ` Ville Syrjälä 2016-11-07 13:07 ` Thomas Gleixner 2016-11-07 13:07 ` Thomas Gleixner 2016-11-07 16:45 ` Ville Syrjälä 2016-11-07 16:45 ` Ville Syrjälä 2016-11-09 3:54 ` Feng Tang 2016-11-09 3:54 ` Feng Tang 2016-11-09 6:08 ` Linus Torvalds 2016-11-09 6:08 ` Linus Torvalds 2016-11-17 17:14 ` Ville Syrjälä 2016-11-17 17:14 ` Ville Syrjälä 2016-05-11 13:36 ` Rafael J. Wysocki 2016-05-11 15:25 ` Jim Bos 2016-05-11 16:19 ` Rafael J. Wysocki 2016-05-11 16:21 ` Sebastian Andrzej Siewior 2016-05-11 16:24 ` Rafael J. Wysocki 2016-05-11 12:44 ` Arjan van de Ven 2016-05-11 15:26 ` Arjan van de Ven 2016-05-11 17:09 ` Ville Syrjälä
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20161027203745.GH4617@intel.com \ --to=ville.syrjala@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=arjan@linux.intel.com \ --cc=bigeasy@linutronix.de \ --cc=feng.79.tang@gmail.com \ --cc=feng.tang@intel.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=oleg@redhat.com \ --cc=paulmck@linux.vnet.ibm.com \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=rafael.j.wysocki@intel.com \ --cc=rafael@kernel.org \ --cc=riel@redhat.com \ --cc=rostedt@goodmis.org \ --cc=rui.zhang@intel \ --cc=rusty@rustcorp.com.au \ --cc=srivatsa@mit.edu \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.