Re: [PATCH] mm,page_alloc: Split stall warning and failure warning.

[Michal Hocko <mhocko@kernel.org>]

On Tue 11-04-17 20:43:05, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Mon 10-04-17 15:03:08, Andrew Morton wrote:
> > > On Mon, 10 Apr 2017 20:58:13 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> > > 
> > > > Patch "mm: page_alloc: __GFP_NOWARN shouldn't suppress stall warnings"
> > > > changed to drop __GFP_NOWARN when calling warn_alloc() for stall warning.
> > > > Although I suggested for two times to drop __GFP_NOWARN when warn_alloc()
> > > > for stall warning was proposed, Michal Hocko does not want to print stall
> > > > warnings when __GFP_NOWARN is given [1][2].
> > > > 
> > > >  "I am not going to allow defining a weird __GFP_NOWARN semantic which
> > > >   allows warnings but only sometimes. At least not without having a proper
> > > >   way to silence both failures _and_ stalls or just stalls. I do not
> > > >   really thing this is worth the additional gfp flag."
> > > 
> > > I interpret __GFP_NOWARN to mean "don't warn about this allocation
> > > attempt failing", not "don't warn about anything at all".  It's a very
> > > minor issue but yes, methinks that stall warning should still come out.
> > 
> > This is what the patch from Johannes already does and you have it in the
> > mmotm tree.
> > 
> > > Unless it's known to cause a problem for the stall warning to come out
> > > for __GFP_NOWARN attempts?  If so then perhaps a
> > > __GFP_NOWARN_ABOUT_STALLS is needed?
> > 
> > And this is one of the reason why I didn't like it. But whatever it
> > doesn't make much sense to spend too much time discussing this again.
> > This patch doesn't really fix anything important IMHO and it just
> > generates more churn.
> 
> This patch does not fix anything important for Michal Hocko, but
> this patch does find something important (e.g. GFP_NOFS | __GFP_NOWARN
> allocations)

I fail to see where it does that.

> for administrators and troubleshooting staffs at support
> centers. As a troubleshooting staff, giving administrators some clue to
> start troubleshooting is critically important.
> 
> Speak from my experience, hardcoded 10 seconds is really useless.
> Some cluster system has only 10 seconds timeout for failover. Failing
> to report allocations stalls longer than a few seconds can make this
> warn_alloc() pointless. On the other hand, some administrators do not
> want to receive this warn_alloc(). If we had tunable interface like
> /proc/sys/kernel/memalloc_task_warning_secs , we can handle both cases
> (assuming that stalling allocations can reach this warn_alloc() within
> a few seconds; if this assumption does not hold, only allocation watchdog
> can handle it).

This repeating of "hypotetical" demand of tunable is getting boring. I
would really appreciate to see at least _one_ such report from the
field. If you do not have any please stop wasting others people time by
unfounded claims.

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