mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	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>
Subject: Re: [nohz] 2a16fc93d2c: kernel lockup on idle injection
Date: Tue, 16 Dec 2014 17:54:58 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1412161741480.17382@nanos> (raw)
In-Reply-To: <20141216145653.GY3337@twins.programming.kicks-ass.net>

On Tue, 16 Dec 2014, Peter Zijlstra wrote:
> On Tue, Dec 16, 2014 at 03:32:28PM +0100, Thomas Gleixner wrote:
> So let me try and understand the problem with the emulated idle thing
> better (running idle from FIFO threads).
> 
> I suppose the tricky bit is what happens when the cpu was idle; in that
> case we'll end up with 1 running thread in state:
> 
>  1              0               1               valid
> 
> But need to avoid ending up in:
> 
>  1              1               1               BUG
> 
> Which should be relatively simple by never entering nohzfull when 'idle'.

Well, yes. 
 
> However with your proposed thingy, I think we'll end up in:
> 
>  1              1               1               BUG
> 
> Because we don't start another thread, so infullnohz will stay valid,
> however we'll also be 'forced' into idle (with nr_running > 0) and stop
> the tick.

Indeed.
 
> A remote wakeup might result in nr_running going from 1->2 and seeing
> infullnohz == 1, try and restart the tick, while we're idle!
> 
> Of course, we can fix that too, by clearing nohzfull when going 'idle',
> after all, nohzfull will re-establish itself automagically when the tick
> detects but the one task afterwards.
> 
> So both cases need work, neither works out of the box afaict. But I

Agreed.

> can't see one really being better than the other either -- am I missing
> obvious things again?

No, it's both butt ugly, though what really bothers me is that we
pretend to be idle without being in the idle thread. That makes a lot
of stuff really weird.

Anything which relies on is_idle_task(current), idle_cpu() and a bunch
of other things just fail to work while we pretend being "the idle"
task.

That's just wrong. That powerclamp stuff needs to put the cpu
(including the scheduler, etc.) into a well defined state.

The fake idle task is everything else than well defined state, really.

Thanks,

	tglx

   


  reply	other threads:[~2014-12-16 16:55 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
2014-12-16 14:56                 ` Peter Zijlstra
2014-12-16 16:54                   ` Thomas Gleixner [this message]
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.1412161741480.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®