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 22:20:06 +0300 [thread overview]
Message-ID: <20161027192006.GF4617@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1610272035180.4913@nanos>
On Thu, Oct 27, 2016 at 08:48:57PM +0200, Thomas Gleixner wrote:
> On Thu, 27 Oct 2016, Ville Syrjälä wrote:
> > On Tue, Aug 09, 2016 at 08:20:57PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jul 14, 2016 at 04:29:42PM +0800, Feng Tang wrote:
> > > > if you only want it to work, you can try an old patch
> > > > https://bugzilla.kernel.org/attachment.cgi?id=76071 from a similar bug
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=41932
> > > >
> > > > Alistair Buxton confirmed it work for 3.18 at least
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=107151#c16
> > >
> > > That patch is a bit too ripe by now. Would need a fresh squeezed one.
> >
> > Since no one else bothered to refresh the patch I did it myself:
> >
> > diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> > index f6aae7977824..d73d094a8972 100644
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -657,8 +657,16 @@ static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
> > * - There are pending events on sleeping CPUs which were not
> > * in the event mask
> > */
> > - if (next_event.tv64 != KTIME_MAX)
> > + if (next_event.tv64 != KTIME_MAX) {
> > + s64 delta = next_event.tv64 - now.tv64;
> > +
> > + if (delta >= 10000000000) {
> > + printk(KERN_CRIT "%s(): The delta is big: %lld\n", __func__, delta);
> > + next_event.tv64 = now.tv64 + 3000000000;
> > + }
> > +
> > tick_broadcast_set_event(dev, next_cpu, next_event);
> > + }
> >
> > raw_spin_unlock(&tick_broadcast_lock);
> >
> > Unfortunately it doesn't do anything for me.
>
> And I'm not surprised, because the original patch forced a 5 seconds event
> in the broadcast device on resume, aside of limiting the reprogramming.
>
> 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.
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f6aae7977824..e2173aeeb00c 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -507,8 +507,12 @@ void tick_resume_broadcast(void)
tick_broadcast_start_periodic(bc);
break;
case TICKDEV_MODE_ONESHOT:
- if (!cpumask_empty(tick_broadcast_mask))
+ if (!cpumask_empty(tick_broadcast_mask)) {
tick_resume_broadcast_oneshot(bc);
+ clockevents_program_event(bc,
+ ktime_add_ns(ktime_get(), 5 * NSEC_PER_SEC),
+ 1);
+ }
break;
}
}
@@ -657,8 +661,16 @@ static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
* - There are pending events on sleeping CPUs which were not
* in the event mask
*/
- if (next_event.tv64 != KTIME_MAX)
+ if (next_event.tv64 != KTIME_MAX) {
+ s64 delta = next_event.tv64 - now.tv64;
+
+ if (delta >= 10000000000) {
+ printk(KERN_CRIT "%s(): The delta is big: %lld\n", __func__, delta);
+ next_event.tv64 = now.tv64 + 3000000000;
+ }
+
tick_broadcast_set_event(dev, next_cpu, next_event);
+ }
raw_spin_unlock(&tick_broadcast_lock);
>
> > The fortunate thing is that acpi-idle has magically been fixed in the
> > meantime, so I can at least go back to using that one and have working
> > S3.
>
> 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
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2016-10-27 19:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160511101920.GZ4329@intel.com>
[not found] ` <57332171.8070403@linutronix.de>
[not found] ` <20160511122116.GA4329@intel.com>
2016-05-11 13:36 ` S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")] 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
[not found] ` <20160511084445.00030b49@gandalf.local.home>
[not found] ` <20160511133406.GC4329@intel.com>
[not found] ` <20160516193910.GL4329@intel.com>
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-07-13 14:54 ` Ville Syrjälä
2016-07-14 8:29 ` Feng Tang
2016-08-09 17:20 ` Ville Syrjälä
2016-10-27 17:28 ` Ville Syrjälä
2016-10-27 18:48 ` Thomas Gleixner
2016-10-27 19:20 ` Ville Syrjälä [this message]
2016-10-27 19:25 ` Thomas Gleixner
2016-10-27 20:37 ` Ville Syrjälä
2016-10-27 20:41 ` Thomas Gleixner
2016-10-28 15:56 ` Ville Syrjälä
2016-10-28 18:58 ` Thomas Gleixner
2016-11-01 20:47 ` Ville Syrjälä
2016-11-07 11:49 ` Ville Syrjälä
2016-11-07 13:07 ` Thomas Gleixner
2016-11-07 16:45 ` Ville Syrjälä
2016-11-09 3:54 ` Feng Tang
2016-11-09 6:08 ` Linus Torvalds
2016-11-17 17:14 ` 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=20161027192006.GF4617@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).