From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751957AbbKYVCA (ORCPT ); Wed, 25 Nov 2015 16:02:00 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:36574 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751007AbbKYVB6 (ORCPT ); Wed, 25 Nov 2015 16:01:58 -0500 Date: Wed, 25 Nov 2015 13:01:56 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Andrew Morton , Mel Gorman , Johannes Weiner , linux-mm@kvack.org, LKML Subject: Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures In-Reply-To: <20151125115527.GF27283@dhcp22.suse.cz> Message-ID: References: <1448448054-804-1-git-send-email-mhocko@kernel.org> <1448448054-804-3-git-send-email-mhocko@kernel.org> <20151125115527.GF27283@dhcp22.suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Nov 2015, Michal Hocko wrote: > > > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags, > > > if (zonelist_rescan) > > > goto zonelist_scan; > > > > > > + /* WARN only once unless min_free_kbytes is updated */ > > > + if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) { > > > + warn_alloc_no_wmarks = 0; > > > + WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x." > > > + " You might consider increasing min_free_kbytes\n", > > > + order, gfp_mask); > > > + } > > > return NULL; > > > } > > > > > > > Doesn't this warn for high-order allocations prior to the first call to > > direct compaction whereas min_free_kbytes may be irrelevant? > > Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation > which happen prior to compaction, right? I am wondering whether there > are reasonable chances that a compaction would make a difference if we > are so depleted that there is no single page with >= order. > ALLOC_NO_WATERMARKS with high order allocations should be rare if > existing at all. > No, I'm concerned about get_page_from_freelist() failing for an order-9 allocation due to _fragmentation_ and then emitting this warning although free watermarks may be gigabytes of memory higher than min watermarks. > > Providing > > the order is good, but there's no indication when min_free_kbytes may be > > helpful from this warning. > > I am not sure I understand what you mean here. > You show the order of the failed allocation in your new warning. Good. It won't help to raise min_free_kbytes to infinity if the high-order allocation failed due to fragmentation. Does that make sense? > > WARN() isn't even going to show the state of memory. > > I was considering to do that but it would make the code unnecessarily > more complex. If the allocation is allowed to fail it would dump the > allocation failure. The purpose of the message is to tell us that > reserves are not sufficient. I am not sure seeing the memory state dump > would help us much more. > If the purpsoe of the message is to tell us when reserves are insufficient, it doesn't achieve that purpose if allocations fail due to fragmentation or lowmem_reserve_ratio.