Re: [mmotm-2016-07-18-16-40] page allocation failure: order:2, mode:0x2000000(GFP_NOWAIT)

From: Alexander Potapenko <glider@google.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.cz>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	riel@redhat.com, David Rientjes <rientjes@google.com>,
	mgorman@techsingularity.net
Subject: Re: [mmotm-2016-07-18-16-40] page allocation failure: order:2, mode:0x2000000(GFP_NOWAIT)
Date: Thu, 21 Jul 2016 13:33:26 +0200	[thread overview]
Message-ID: <CAG_fn=UppxF7NY7HAtq6DvK-wqizCKmEw=vQ0+rjYErGbHjsvg@mail.gmail.com> (raw)
In-Reply-To: <20160720223427.GA22911@node.shutemov.name>

On Thu, Jul 21, 2016 at 12:34 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Wed, Jul 20, 2016 at 08:12:13PM +0200, Alexander Potapenko wrote:
>> >>>>> It's easy to reproduce in my setup: virtual machine with some amount of
>> >>>>> swap space and try allocate about the size of RAM in userspace (I used
>> >>>>> usemem[1] for that).
>>
>> Am I understanding right that you're seeing allocation failures from
>> the stack depot? How often do they happen? Are they reported under
>> heavy load, or just when you boot the kernel?
>
> As I described, it happens under memory pressure.
>
>> Allocating with __GFP_NOWARN will help here, but I think we'd better
>> figure out what's gone wrong.
>> I've sent https://lkml.org/lkml/2016/7/14/566, which should reduce the
>> stack depot's memory consumption, for review - can you see if the bug
>> is still reproducible with that?
>
> I was not able to trigger the failure with the same test case.
> Tested with v2 of the patch.
When the allocation happens in IRQ handler, we try to be clever and
cut everything below EOI, because the lower frames don't really
matter, but prevent stack deduplication.
But since the stack pointers aren't preserved in the stack trace, the
only way to do so is to check whether each frame is an IRQ entry
point.
That patch adds several entry points to the .irqentry.text section,
thus allowing the stack depot to filter them out as well.
If that works for you, we'd better not add the __GFP_NOWARN flag -
that way we'll be able to detect similar problems in the future.

> (Links to http://lkml.kernel.org/ or other archive with message-id in url
> is prefered. lkml.org is garbage)
Does gmane.org work (e.g. http://article.gmane.org/gmane.linux.kernel/2266971)
It is surprisingly tricky to figure out a message id from the subject.
> --
>  Kirill A. Shutemov


-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

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