All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Is it safe for kthreadd to drain_all_pages?
Date: Thu, 6 Apr 2017 14:06:14 +0100	[thread overview]
Message-ID: <20170406130614.a6ygueggpwseqysd@techsingularity.net> (raw)
In-Reply-To: <alpine.LSU.2.11.1704051331420.4288@eggly.anvils>

On Wed, Apr 05, 2017 at 01:59:49PM -0700, Hugh Dickins wrote:
> Hi Mel,
> 
> I suspect that it's not safe for kthreadd to drain_all_pages();
> but I haven't studied flush_work() etc, so don't really know what
> I'm talking about: hoping that you will jump to a realization.
> 

You're right, it's not safe. If kthreadd is creating the workqueue
thread to do the drain and it'll recurse into itself.

> 4.11-rc has been giving me hangs after hours of swapping load.  At
> first they looked like memory leaks ("fork: Cannot allocate memory");
> but for no good reason I happened to do "cat /proc/sys/vm/stat_refresh"
> before looking at /proc/meminfo one time, and the stat_refresh stuck
> in D state, waiting for completion of flush_work like many kworkers.
> kthreadd waiting for completion of flush_work in drain_all_pages().
> 

It's asking itself to do work in all likelihood.

> Patch below has been running well for 36 hours now:
> a bit too early to be sure, but I think it's time to turn to you.
> 

I think the patch is valid but like Michal, would appreciate if you
could run the patch he linked to see if it also side-steps the same
problem. 

Good spot!

-- 
Mel Gorman
SUSE Labs

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Is it safe for kthreadd to drain_all_pages?
Date: Thu, 6 Apr 2017 14:06:14 +0100	[thread overview]
Message-ID: <20170406130614.a6ygueggpwseqysd@techsingularity.net> (raw)
In-Reply-To: <alpine.LSU.2.11.1704051331420.4288@eggly.anvils>

On Wed, Apr 05, 2017 at 01:59:49PM -0700, Hugh Dickins wrote:
> Hi Mel,
> 
> I suspect that it's not safe for kthreadd to drain_all_pages();
> but I haven't studied flush_work() etc, so don't really know what
> I'm talking about: hoping that you will jump to a realization.
> 

You're right, it's not safe. If kthreadd is creating the workqueue
thread to do the drain and it'll recurse into itself.

> 4.11-rc has been giving me hangs after hours of swapping load.  At
> first they looked like memory leaks ("fork: Cannot allocate memory");
> but for no good reason I happened to do "cat /proc/sys/vm/stat_refresh"
> before looking at /proc/meminfo one time, and the stat_refresh stuck
> in D state, waiting for completion of flush_work like many kworkers.
> kthreadd waiting for completion of flush_work in drain_all_pages().
> 

It's asking itself to do work in all likelihood.

> Patch below has been running well for 36 hours now:
> a bit too early to be sure, but I think it's time to turn to you.
> 

I think the patch is valid but like Michal, would appreciate if you
could run the patch he linked to see if it also side-steps the same
problem. 

Good spot!

-- 
Mel Gorman
SUSE Labs

  parent reply	other threads:[~2017-04-06 13:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 20:59 Is it safe for kthreadd to drain_all_pages? Hugh Dickins
2017-04-05 20:59 ` Hugh Dickins
2017-04-06  8:55 ` Michal Hocko
2017-04-06  8:55   ` Michal Hocko
2017-04-06 13:06 ` Mel Gorman [this message]
2017-04-06 13:06   ` Mel Gorman
2017-04-06 18:52   ` Hugh Dickins
2017-04-06 18:52     ` Hugh Dickins
2017-04-07 16:25     ` Hugh Dickins
2017-04-07 16:25       ` Hugh Dickins
2017-04-07 16:39       ` Michal Hocko
2017-04-07 16:39         ` Michal Hocko
2017-04-07 16:58         ` Hugh Dickins
2017-04-07 16:58           ` Hugh Dickins
2017-04-07 17:29           ` Michal Hocko
2017-04-07 17:29             ` Michal Hocko
2017-04-07 18:46             ` Hugh Dickins
2017-04-07 18:46               ` Hugh Dickins
2017-04-08 17:04               ` Hugh Dickins
2017-04-08 17:04                 ` Hugh Dickins
2017-04-08 18:09                 ` Mel Gorman
2017-04-08 18:09                   ` Mel Gorman
2017-04-13 17:56                   ` Andrea Arcangeli
2017-04-13 17:56                     ` Andrea Arcangeli

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=20170406130614.a6ygueggpwseqysd@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.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 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.