From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751412AbcFBFsk (ORCPT ); Thu, 2 Jun 2016 01:48:40 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:36432 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750731AbcFBFsj (ORCPT ); Thu, 2 Jun 2016 01:48:39 -0400 MIME-Version: 1.0 In-Reply-To: <20160531131520.GI24936@arm.com> References: <574D64A0.2070207@arm.com> <60e8df74202e40b28a4d53dbc7fd0b22@IL-EXCH02.marvell.com> <20160531131520.GI24936@arm.com> Date: Thu, 2 Jun 2016 07:48:38 +0200 Message-ID: Subject: Re: [BUG] Page allocation failures with newest kernels From: Marcin Wojtas To: Will Deacon Cc: Yehuda Yitschak , Robin Murphy , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Lior Amsalem , Thomas Petazzoni , Catalin Marinas , Arnd Bergmann , Grzegorz Jaszczyk , Nadav Haklai , Tomasz Nowicki , =?UTF-8?Q?Gregory_Cl=C3=A9ment?= , mgorman@techsingularity.net Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, I think I found a right trace. Following one-liner fixes the issue beginning from v4.2-rc1 up to v4.4 included: --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -294,7 +294,7 @@ static inline bool early_page_uninitialised(unsigned long pfn) static inline bool early_page_nid_uninitialised(unsigned long pfn, int nid) { - return false; + return true; } The regression was introduced by commit 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in parallel with kswapd"), which in fact disabled memblock reserve at all for all platfroms not using CONFIG_DEFERRED_STRUCT_PAGE_INIT (x86 is the only user), hence temporary shortage of memory possible to allocate during my test. Since v4.4-rc1 following changes of approach have been introduced: 97a16fc - mm, page_alloc: only enforce watermarks for order-0 allocations 0aaa29a - mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand 974a786 - mm, page_alloc: remove MIGRATE_RESERVE >>From what I understood, now order-0 allocation keep no reserve at all. I checked all gathered logs and indeed it was order-0 which failed and apparently weren't able to reclaim successfully. Since the problem is very easy to reproduce (at least in my test, as well as stressing device in NAS setup) is there any chance to avoid destiny of page alloc failures? Or any trick to play with fragmentation parameters, etc.? I would be grateful for any hint. Best regards, Marcin 2016-05-31 15:15 GMT+02:00 Will Deacon : > On Tue, May 31, 2016 at 01:10:44PM +0000, Yehuda Yitschak wrote: >> During some of the stress tests we also came across a different warning >> from the arm64 page management code >> It looks like a race is detected between HW and SW marking a bit in the PTE > > A72 (which I believe is the CPU in that SoC) is a v8.0 CPU and therefore > doesn't have hardware DBM. > >> Not sure it's really related but I thought it might give a clue on the issue >> http://pastebin.com/ASv19vZP > > There have been a few patches from Catalin to fix up the hardware DBM > patches, so it might be worth trying to reproduce this failure with a > more recent kernel. I doubt this is related to the allocation failures, > however. > > Will