linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: hannes@cmpxchg.org, riel@redhat.com, akpm@linux-foundation.org,
	mgorman@suse.de, vbabka@suse.cz, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever
Date: Fri, 30 Jun 2017 18:19:08 +0200	[thread overview]
Message-ID: <20170630161907.GC9714@dhcp22.suse.cz> (raw)
In-Reply-To: <201707010059.EAE43714.FOVOMOSLFHJFQt@I-love.SAKURA.ne.jp>

On Sat 01-07-17 00:59:56, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Fri 30-06-17 09:14:22, Tetsuo Handa wrote:
> > [...]
> > > Ping? Ping? When are we going to apply this patch or watchdog patch?
> > > This problem occurs with not so insane stress like shown below.
> > > I can't test almost OOM situation because test likely falls into either
> > > printk() v.s. oom_lock lockup problem or this too_many_isolated() problem.
> > 
> > So you are saying that the patch fixes this issue. Do I understand you
> > corretly? And you do not see any other negative side effectes with it
> > applied?
> 
> I hit this problem using http://lkml.kernel.org/r/20170626130346.26314-1-mhocko@kernel.org
> on next-20170628. We won't be able to test whether the patch fixes this issue without
> seeing any other negative side effects without sending this patch to linux-next.git.
> But at least we know that even this patch is sent to linux-next.git, we will still see
> bugs like http://lkml.kernel.org/r/201703031948.CHJ81278.VOHSFFFOOLJQMt@I-love.SAKURA.ne.jp .

It is really hard to pursue this half solution when there is no clear
indication it helps in your testing. So could you try to test with only
this patch on top of the current linux-next tree (or Linus tree) and see
if you can reproduce the problem?

It is possible that there are other potential problems but we at least
need to know whether it is worth going with the patch now.
 
[...]
> > Rik, Johannes what do you think? Should we go with the simpler approach
> > for now and think of a better plan longterm?
> 
> I don't hurry if we can check using watchdog whether this problem is occurring
> in the real world. I have to test corner cases because watchdog is missing.
> 
> Watchdog does not introduce negative side effects, will avoid soft lockups like
> http://lkml.kernel.org/r/CAM_iQpWuPVGc2ky8M-9yukECtS+zKjiDasNymX7rMcBjBFyM_A@mail.gmail.com ,
> will avoid console_unlock() v.s. oom_lock mutext lockups due to warn_alloc(),
> will catch similar bugs which people are failing to reproduce.

this way of pushing your patch is really annoying. Please do realize
that repeating the same thing all around will not make a patch more
likely to merge. You have proposed something, nobody has nacked it
so it waits for people to actually find it important enough to justify
the additional code. So please stop this.

I really do appreciate your testing because it uncovers corner cases
most people do not test for and we can actually make the code better in
the end.
-- 
Michal Hocko
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>

  reply	other threads:[~2017-06-30 16:19 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-07 13:30 [PATCH] mm, vmscan: do not loop on too_many_isolated for ever Michal Hocko
2017-03-07 19:52 ` Rik van Riel
2017-03-08  9:21   ` Michal Hocko
2017-03-08 15:54     ` Rik van Riel
2017-03-09  9:12       ` Michal Hocko
2017-03-09 14:16         ` Rik van Riel
2017-03-09 14:59           ` Michal Hocko
2017-03-09 18:05   ` Johannes Weiner
2017-03-09 22:18     ` Rik van Riel
2017-03-10 10:27       ` Michal Hocko
2017-03-10 10:20     ` Michal Hocko
2017-03-10 11:44       ` Tetsuo Handa
2017-03-21 10:37         ` Tetsuo Handa
2017-04-23 10:24         ` Tetsuo Handa
2017-04-24 12:39           ` Stanislaw Gruszka
2017-04-24 13:06             ` Tetsuo Handa
2017-04-25  6:33               ` Stanislaw Gruszka
2017-06-30  0:14         ` Tetsuo Handa
2017-06-30 13:32           ` Michal Hocko
2017-06-30 15:59             ` Tetsuo Handa
2017-06-30 16:19               ` Michal Hocko [this message]
2017-07-01 11:43                 ` Tetsuo Handa
2017-07-05  8:19                   ` Michal Hocko
2017-07-05  8:20                   ` Michal Hocko
2017-07-06 10:48                     ` Tetsuo Handa
2017-03-09 14:31 ` Mel Gorman
2017-07-10  7:48 Michal Hocko
2017-07-10 13:16 ` Vlastimil Babka
2017-07-10 13:58 ` Rik van Riel
2017-07-10 16:58   ` Johannes Weiner
2017-07-10 17:09     ` Michal Hocko
2017-07-19 22:20 ` Andrew Morton
2017-07-20  6:56   ` Michal Hocko
2017-07-21 23:01     ` Andrew Morton
2017-07-24  6:50       ` Michal Hocko
2017-07-20  1:54 ` Hugh Dickins
2017-07-20 10:44   ` Tetsuo Handa
2017-07-24  7:01     ` Hugh Dickins
2017-07-24 11:12       ` Tetsuo Handa
2017-07-20 13:22   ` Michal Hocko
2017-07-24  7:03     ` Hugh Dickins

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=20170630161907.GC9714@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=riel@redhat.com \
    --cc=vbabka@suse.cz \
    /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).