linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
	Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org,
	David Rientjes <rientjes@google.com>,
	oleg@redhat.com, kwalker@redhat.com, akpm@linux-foundation.org,
	hannes@cmpxchg.org, vdavydov@parallels.com, skozina@redhat.com,
	mgorman@suse.de, riel@redhat.com
Subject: Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks
Date: Tue, 27 Oct 2015 19:52:48 +0900	[thread overview]
Message-ID: <20151027105248.GA18741@mtj.duckdns.org> (raw)
In-Reply-To: <20151027091603.GB9891@dhcp22.suse.cz>

Hello, Michal.

On Tue, Oct 27, 2015 at 10:16:03AM +0100, Michal Hocko wrote:
> > Seriously, nobody goes full-on RUNNING.
> 
> Looping with cond_resched seems like general pattern in the kernel when
> there is no clear source to wait for. We have io_schedule when we know
> we should wait for IO (in case of congestion) but this is not necessarily
> the case - as you can see here. What should we wait for? A short nap
> without actually waiting on anything sounds like a dirty workaround to
> me.

It's one thing to do cond_resched() in long loops to avoid long
priority inversions and another to indefinitely loop without making
any difference.

> > > guarantee that then I would argue that it should be implicit for
> > > WQ_MEM_RECLAIM otherwise we always risk a similar situation. What would
> > > be a counter argument for doing that?
> > 
> > Not serving any actual purpose and degrading execution behavior.
> 
> I dunno, I am not familiar with WQ internals to see the risks but to me
> it sounds like WQ_MEM_RECLAIM gives an incorrect impression of safety
> wrt. memory pressure and as demonstrated it doesn't do that. Even if you

It generally does.  This is an extremely rare corner case where
infinite loop w/o forward progress is introduce w/o the user being
outright buggy.

> consider cond_resched behavior of the page allocator as bug we should be
> able to handle this gracefully.

We can argue this back and forth forever but we'll either need to
special case it (be it short sleep or a special flag) or implement a
rather complex detection logic which will likely involve some level of
complexity and is dubious in its practical usefulness.  It's a
trade-off and given the circumstances adding short sleep looks like a
reasonable one to me.  If this is more common, we definitely wanna go
for automatic detection.

Thanks.

-- 
tejun

--
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:[~2015-10-27 10:52 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-21 12:26 [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks Tetsuo Handa
2015-10-21 13:03 ` Michal Hocko
2015-10-21 14:22 ` Christoph Lameter
2015-10-21 14:33   ` Michal Hocko
2015-10-21 14:49     ` Christoph Lameter
2015-10-21 14:55       ` Michal Hocko
2015-10-21 15:39         ` Tetsuo Handa
2015-10-21 17:16         ` Christoph Lameter
2015-10-22 11:37           ` Tetsuo Handa
2015-10-22 13:39             ` Christoph Lameter
2015-10-22 14:09               ` Tejun Heo
2015-10-22 14:21                 ` Tejun Heo
2015-10-22 14:23                   ` Christoph Lameter
2015-10-22 14:24                     ` Tejun Heo
2015-10-22 14:25                       ` Christoph Lameter
2015-10-22 14:33                         ` Tejun Heo
2015-10-22 14:41                           ` Christoph Lameter
2015-10-22 15:14                             ` Tejun Heo
2015-10-23  4:26                               ` Tejun Heo
2015-11-02 15:01                                 ` Michal Hocko
2015-11-02 19:20                                   ` Tejun Heo
2015-11-03  2:32                                     ` Tetsuo Handa
2015-11-03 19:43                                       ` Tejun Heo
2015-11-05 14:59                                   ` Tetsuo Handa
2015-11-05 17:45                                     ` Christoph Lameter
2015-11-06  0:16                                       ` Tejun Heo
2015-11-11 15:44                                         ` Michal Hocko
2015-11-11 16:03                                           ` Michal Hocko
2015-10-22 14:22                 ` Christoph Lameter
2015-10-22 15:06                 ` Michal Hocko
2015-10-22 15:15                   ` Tejun Heo
2015-10-22 15:33                     ` Christoph Lameter
2015-10-23  8:37                       ` Michal Hocko
2015-10-23 11:43                         ` Make vmstat deferrable again (was Re: [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks) Christoph Lameter
2015-10-23 12:07                           ` Sergey Senozhatsky
2015-10-23 14:12                             ` Christoph Lameter
2015-10-23 14:49                               ` Sergey Senozhatsky
2015-10-23 16:10                                 ` Christoph Lameter
2015-10-22 15:35                     ` [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks Michal Hocko
2015-10-22 15:37                       ` Tejun Heo
2015-10-22 15:49                         ` Michal Hocko
2015-10-22 18:42                           ` Tejun Heo
2015-10-22 21:42                             ` [PATCH] mm,vmscan: Use accurate values for zone_reclaimable()checks Tetsuo Handa
2015-10-22 22:47                               ` Tejun Heo
2015-10-23  8:36                               ` Michal Hocko
2015-10-23 10:37                                 ` Tejun Heo
2015-10-23  8:33                             ` [PATCH] mm,vmscan: Use accurate values for zone_reclaimable() checks Michal Hocko
2015-10-23 10:36                               ` Tejun Heo
2015-10-23 11:11                                 ` Michal Hocko
2015-10-23 12:25                                   ` Tetsuo Handa
2015-10-23 18:23                                     ` Tejun Heo
2015-10-25 10:52                                       ` Tetsuo Handa
2015-10-25 22:47                                         ` Tejun Heo
2015-10-27  9:22                                         ` Michal Hocko
2015-10-27 10:55                                           ` Tejun Heo
2015-10-27 12:07                                             ` Michal Hocko
2015-10-23 18:21                                   ` Tejun Heo
2015-10-27  9:16                                     ` Michal Hocko
2015-10-27 10:52                                       ` Tejun Heo [this message]
2015-10-27 11:07                                       ` [PATCH] mm,vmscan: Use accurate values for zone_reclaimable()checks Tetsuo Handa
2015-10-27 11:30                                         ` Tejun Heo

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=20151027105248.GA18741@mtj.duckdns.org \
    --to=htejun@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hannes@cmpxchg.org \
    --cc=kwalker@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=oleg@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=skozina@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vdavydov@parallels.com \
    /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).