linux-kernel - Re: [PATCH 2/2] mm: warn about ALLOC_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151125115527.GF27283@dhcp22.suse.cz>
Date:	Wed, 25 Nov 2015 12:55:27 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

On Wed 25-11-15 02:59:19, David Rientjes wrote:
> 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.

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

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

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/