linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	Donald Buczek <buczek@molgen.mpg.de>,
	Paul Menzel <pmenzel@molgen.mpg.de>,
	dvteam@molgen.mpg.de, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Josh Triplett <josh@joshtriplett.org>
Subject: Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`
Date: Thu, 1 Dec 2016 08:59:18 -0800	[thread overview]
Message-ID: <20161201165918.GG3924@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161201163614.GL3092@twins.programming.kicks-ass.net>

On Thu, Dec 01, 2016 at 05:36:14PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 04:40:24AM -0800, Paul E. McKenney wrote:
> > On Thu, Dec 01, 2016 at 06:30:35AM +0100, Peter Zijlstra wrote:
> 
> > > Sure, we all dislike IPIs, but I'm thinking this half-way point is
> > > sensible, no point in issuing user visible annoyance if indeed we can
> > > prod things back to life, no?
> > > 
> > > Only if we utterly fail to make it respond should we bug the user with
> > > our failure..
> > 
> > Sold!  ;-)
> > 
> > I will put together a patch later today.
> > 
> > My intent is to hold off on the "upgrade cond_resched()" patch, one
> > step at a time.  Longer term, I do very much like the idea of having
> > cond_resched() do both scheduling and RCU quiescent states, assuming
> > that this avoids performance pitfalls.
> 
> Well, with the above change cond_resched() is already sufficient, no?

Maybe.  Right now, cond_resched_rcu_qs() gets a quiescent state to
the RCU core in less than one jiffy, with my other change, this becomes
a handful of jiffies depending on HZ and NR_CPUS.  I expect this
increase to a handful of jiffies to be a non-event.

After my upcoming patch, cond_resched() will get a quiescent state to
the RCU core in about ten seconds.  While I am am not all that nervous
about the increase from less than a jiffy to a handful of jiffies,
increasing to ten seconds via cond_resched() does make me quite nervous.
Past experience indicates that someone's kernel will likely be fatally
inconvenienced by this magnitude of change.

Or am I misunderstanding what you are proposing?

> In fact, by doing the IPI thing we get the entire cond_resched*()
> family, and we could add the should_resched() guard to
> cond_resched_rcu().

So that cond_resched_rcu_qs() looks something like this, in order
to avoid the function call in the case where the scheduler has nothing
to do?

#define cond_resched_rcu_qs() \
do { \
	if (!should_resched(current) || !cond_resched()) \
		rcu_note_voluntary_context_switch(current); \
} while (0)

							Thanx, Paul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-12-01 16:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20161108183938.GD4127@linux.vnet.ibm.com>
     [not found] ` <9f87f8f0-9d0f-f78f-8dca-993b09b19a69@molgen.mpg.de>
     [not found]   ` <20161116173036.GK3612@linux.vnet.ibm.com>
     [not found]     ` <20161121134130.GB18112@dhcp22.suse.cz>
     [not found]       ` <20161121140122.GU3612@linux.vnet.ibm.com>
     [not found]         ` <20161121141818.GD18112@dhcp22.suse.cz>
     [not found]           ` <20161121142901.GV3612@linux.vnet.ibm.com>
     [not found]             ` <68025f6c-6801-ab46-b0fc-a9407353d8ce@molgen.mpg.de>
     [not found]               ` <20161124101525.GB20668@dhcp22.suse.cz>
     [not found]                 ` <583AA50A.9010608@molgen.mpg.de>
     [not found]                   ` <20161128110449.GK14788@dhcp22.suse.cz>
2016-11-28 12:26                     ` INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node` Paul Menzel
2016-11-30 10:28                       ` Donald Buczek
2016-11-30 11:09                         ` Michal Hocko
2016-11-30 11:43                           ` Donald Buczek
2016-12-02  9:14                             ` Donald Buczek
2016-12-06  8:32                               ` Donald Buczek
2016-11-30 11:53                           ` Paul E. McKenney
2016-11-30 11:54                             ` Paul E. McKenney
2016-11-30 12:31                               ` Paul Menzel
2016-11-30 14:31                                 ` Paul E. McKenney
2016-11-30 13:19                             ` Michal Hocko
2016-11-30 14:29                               ` Paul E. McKenney
2016-11-30 16:38                                 ` Peter Zijlstra
2016-11-30 17:02                                   ` Paul E. McKenney
2016-11-30 17:05                                   ` Michal Hocko
2016-11-30 17:23                                     ` Paul E. McKenney
2016-11-30 17:34                                       ` Michal Hocko
2016-11-30 17:50                                     ` Peter Zijlstra
2016-11-30 19:40                                       ` Paul E. McKenney
2016-12-01  5:30                                         ` Peter Zijlstra
2016-12-01 12:40                                           ` Paul E. McKenney
2016-12-01 16:36                                             ` Peter Zijlstra
2016-12-01 16:59                                               ` Paul E. McKenney [this message]
2016-12-01 18:09                                                 ` Peter Zijlstra
2016-12-01 18:42                                                   ` Paul E. McKenney
2016-12-01 18:49                                                     ` Peter Zijlstra
     [not found] <d6981bac-8e97-b482-98c0-40949db03ca3@kernelpanic.ru>
     [not found] ` <20161124133019.GE3612@linux.vnet.ibm.com>
     [not found]   ` <de88a72a-f861-b51f-9fb3-4265378702f1@kernelpanic.ru>
     [not found]     ` <20161125212000.GI31360@linux.vnet.ibm.com>
     [not found]       ` <20161128095825.GI14788@dhcp22.suse.cz>
     [not found]         ` <20161128105425.GY31360@linux.vnet.ibm.com>
     [not found]           ` <3a4242cb-0198-0a3b-97ae-536fb5ff83ec@kernelpanic.ru>
     [not found]             ` <20161128143435.GC3924@linux.vnet.ibm.com>
2016-11-28 14:40               ` Boris Zhmurov
2016-11-28 15:05                 ` Paul E. McKenney
2016-11-28 19:16                   ` Boris Zhmurov
2016-11-29 18:59                     ` Paul E. McKenney
2016-11-30 17:41                   ` Boris Zhmurov
2016-11-30 17:48                     ` Michal Hocko
2016-11-30 18:12                       ` Boris Zhmurov
2016-11-30 18:25                         ` Michal Hocko
2016-11-30 18:26                           ` Boris Zhmurov
2016-12-01 18:10                           ` Boris Zhmurov
2016-12-01 19:39                             ` Paul E. McKenney
2016-12-02  9:37                             ` Michal Hocko
2016-12-02 13:52                               ` Paul E. McKenney
2016-12-02 16:39                             ` Boris Zhmurov
2016-12-02 16:44                               ` Paul E. McKenney
2016-12-02 17:02                                 ` Michal Hocko
2016-12-02 17:15                                   ` Paul E. McKenney
2016-11-30 19:42                         ` Paul E. McKenney

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=20161201165918.GG3924@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=buczek@molgen.mpg.de \
    --cc=dvteam@molgen.mpg.de \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmenzel@molgen.mpg.de \
    /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).