mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	LKML <linux-kernel@vger.kernel.org>, LKP <lkp@01.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [nohz] 2a16fc93d2c: kernel lockup on idle injection
Date: Tue, 16 Dec 2014 15:32:28 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1412161510000.17382@nanos> (raw)
In-Reply-To: <alpine.DEB.2.11.1412161105470.17382@nanos>

On Tue, 16 Dec 2014, Thomas Gleixner wrote:
> Now the powerclamp mess is a different story.
> 
> Calling tick_nohz_idle_enter()/exit() from outside the idle task is
> just broken. Period.
> 
> Trying to work around that madness in the core code is just fiddling
> with the symptoms and ignoring the root cause. And the root cause is
> simply that powerclamp calls tick_nohz_idle_enter()/exit().

The only sane solution for that insanity is to rip out the thread code
from powerclamp and replace it with a simple per cpu timer.

timerfn() 
{
   too_hot = magic();
   sched_fair_this_cpu_wreckaged(too_hot);   
   restart_clamp_timer();
}

And have the following in sched

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index df2cdf77f899..d257b62ee533 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4989,6 +4989,34 @@ preempt:
 		set_last_buddy(se);
 }
 
+#ifdef CONFIG_WRECKAGE_SCHED_FAIR
+static struct static_key wreckage_key = STATIC_KEY_INIT;
+static DEFINE_PER_CPU(cpu_is_wreckaged, bool);
+
+void sched_fair_this_cpu_wreckaged(bool wreckaged)
+{
+	this_cpu_write(sched_block_fair, wreckaged);
+}
+
+void sched_fair_cpu_wreckage_control(bool on)
+{
+	if (on)
+		static_key_slow_inc(&wreckage_key);
+	else
+		static_key_slow_dec(&wreckage_key);
+}
+
+static inline bool class_fair_disabled(void)
+{
+	if (static_key_false(&wreckage_key))
+		return false;
+	return this_cpu_read(sched_block_fair);
+}
+
+#else
+static inline bool class_fair_disabled(void) { return false; }
+#endif
+
 static struct task_struct *
 pick_next_task_fair(struct rq *rq, struct task_struct *prev)
 {
@@ -4997,6 +5025,8 @@ pick_next_task_fair(struct rq *rq, struct task_struct *prev)
 	struct task_struct *p;
 	int new_tasks;
 
+	if (class_fair_disabled())
+		goto idle;
 again:
 #ifdef CONFIG_FAIR_GROUP_SCHED
 	if (!cfs_rq->nr_running)

The static key is enabled once the powerclamp mess starts. So nobody
else than powerclamp users are affected by this and rightfully so.

Not pretty, but better than a gazillion workarounds all over the place
to make "pretending I'm idle" actually work. This is basically the
same mechanism as we have with the RT throttler, where a RT hog will
be put onto hold for some time. We just put all sched other tasks on
hold while still allowing RT tasks and everything else to work.

Thoughts?

Thanks,

	tglx

  parent reply	other threads:[~2014-12-16 14:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-11 19:42 Fengguang Wu
2014-12-12 11:57 ` Viresh Kumar
2014-12-15  7:25   ` Preeti U Murthy
2014-12-15  9:32     ` Viresh Kumar
2014-12-15  9:43       ` Preeti U Murthy
2014-12-15 21:24         ` Pan, Jacob jun
2014-12-16  4:18           ` Viresh Kumar
2014-12-16 17:15             ` Jacob Pan
2014-12-16 21:15               ` Thomas Gleixner
2014-12-15 23:44       ` Frederic Weisbecker
2014-12-16  4:53         ` Viresh Kumar
2014-12-16  9:36           ` Preeti U Murthy
2014-12-16 12:49             ` Thomas Gleixner
2014-12-16 14:20               ` Frederic Weisbecker
2014-12-16 14:50                 ` Thomas Gleixner
2014-12-16 21:21                   ` Thomas Gleixner
2014-12-16 22:49                     ` Peter Zijlstra
2014-12-16 22:54                       ` Thomas Gleixner
2014-12-17  0:26                         ` Frederic Weisbecker
2014-12-17  0:12                     ` Frederic Weisbecker
2014-12-17  9:11                       ` Thomas Gleixner
2014-12-17 12:47                         ` Frederic Weisbecker
2014-12-16 14:32               ` Thomas Gleixner [this message]
2014-12-16 14:56                 ` Peter Zijlstra
2014-12-16 16:54                   ` Thomas Gleixner
2014-12-17 12:31               ` Preeti Murthy
2014-12-17 15:42                 ` Thomas Gleixner

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=alpine.DEB.2.11.1412161510000.17382@nanos \
    --to=tglx@linutronix.de \
    --cc=fengguang.wu@intel.com \
    --cc=frederic@kernel.org \
    --cc=fweisbec@gmail.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@01.org \
    --cc=peterz@infradead.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=viresh.kumar@linaro.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

all inboxes | Powered by JetHome®