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

From: Michal Hocko <mhocko@kernel.org>
To: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: David Rientjes <rientjes@google.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	hannes@cmpxchg.org
Subject: Re: [PATCH] mm,page_alloc: Split stall warning and failure warning.
Date: Mon, 24 Apr 2017 10:42:17 +0200	[thread overview]
Message-ID: <20170424084216.GB1739@dhcp22.suse.cz> (raw)
In-Reply-To: <20170422081030.GA5476@redhat.com>

On Sat 22-04-17 10:10:34, Stanislaw Gruszka wrote:
[...]
> > This whole special casing
> > of debug_guardpage_minorder is just too strange to me. We do have a rate
> > limit to not flood the log.
> 
> I added this check to skip warning if buddy allocator fail, what I
> considered likely scenario taking the conditions. The check remove
> warning completely, rate limit only limit the speed warnings shows in
> logs.

Yes and this is what I argue against. The feature limits the amount of
_usable_ memory and as such it changes the behavior of the allocator
which can lead to all sorts of problems (including high memory pressure,
stalls, OOM etc.). The warning is there to help debug all those
problems and removing it just changes that behavior in an unexpected
way. This is just wrong thing to do IMHO. Even worse so when it
motivates to make other code in the allocator more complicated. If there
is really a problem logs flooded by the allocation failures while using
the guard page we should address it by a more strict ratelimiting.
-- 
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>