Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753305AbbKAXUo (ORCPT <rfc822;w@1wt.eu>);
	Sun, 1 Nov 2015 18:20:44 -0500
Received: from mga11.intel.com ([192.55.52.93]:43448 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753087AbbKAXUk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 1 Nov 2015 18:20:40 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,230,1444719600"; 
   d="scan'208";a="840206014"
From: "Huang\, Ying" <ying.huang@linux.intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Mel Gorman <mgorman@techsingularity.net>, lkp@01.org,
        LKML <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Rik van Riel <riel@redhat.com>, Vitaly Wool <vitalywool@gmail.com>,
        David Rientjes <rientjes@google.com>, Christoph Lameter <cl@linux.com>,
        Johannes Weiner <hannes@cmpxchg.org>, Vlastimil Babka <vbabka@suse.cz>,
        Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [lkp] [mm, page_alloc] 43993977ba: +88% OOM possibility
References: <87oafjpnb1.fsf@yhuang-dev.intel.com>
	<20151029142440.GE23598@dhcp22.suse.cz>
	<87si4szrzf.fsf@yhuang-dev.intel.com>
	<20151030103830.GJ18429@dhcp22.suse.cz>
Date: Mon, 02 Nov 2015 07:20:37 +0800
In-Reply-To: <20151030103830.GJ18429@dhcp22.suse.cz> (Michal Hocko's message
	of "Fri, 30 Oct 2015 11:38:30 +0100")
Message-ID: <87poztfgsa.fsf@yhuang-dev.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3022
Lines: 67

Michal Hocko <mhocko@kernel.org> writes:

> On Fri 30-10-15 16:21:40, Huang, Ying wrote:
>> Michal Hocko <mhocko@kernel.org> writes:
>> 
>> > On Wed 28-10-15 13:36:02, kernel test robot wrote:
>> >> FYI, we noticed the below changes on
>> >> 
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> >> commit 43993977baecd838d66ccabc7f682342fc6ff635 ("mm, page_alloc:
>> >> distinguish between being unable to sleep, unwilling to sleep and
>> >> avoiding waking kswapd")
>> >> 
>> >> We found the OOM possibility increased 88% in a virtual machine with 1G memory.
>> >
>> > Could you provide dmesg output from this test?
>> 
>> Sure, Attached.
>
> I can only see a single allocation failure warning:
> kworker/u4:1: page allocation failure: order:0, mode:0x2204000
>
> This is obviously a non sleeping allocation with ___GFP_KSWAPD_RECLAIM
> set. ___GFP_HIGH (aka access to memory reserves) is not required so a
> failure of such an allocation is something to be expected.
>
> [ 2294.616369] Workqueue: btrfs-submit btrfs_submit_helper
> [ 2294.616369]  0000000000000000 ffff88000d38f5e0 ffffffff8173f84c 0000000000000000
> [ 2294.616369]  ffff88000d38f678 ffffffff811abaee 00000000ffffffff 000000010038f618
> [ 2294.616369]  ffff8800584e4148 00000000ffffffff ffff8800584e2f00 0000000000000001
> [ 2294.616369] Call Trace:
> [ 2294.616369]  [<ffffffff8173f84c>] dump_stack+0x4b/0x63
> [ 2294.616369]  [<ffffffff811abaee>] warn_alloc_failed+0x125/0x13d
> [ 2294.616369]  [<ffffffff811aecce>] __alloc_pages_nodemask+0x7c9/0x915
> [ 2294.616369]  [<ffffffff811ecc7b>] kmem_getpages+0x91/0x155
> [ 2294.616369]  [<ffffffff811eef0d>] fallback_alloc+0x1cc/0x24c
> [ 2294.616369]  [<ffffffff811eed32>] ____cache_alloc_node+0x151/0x160
> [ 2294.616369]  [<ffffffff811ef1ed>] __kmalloc+0xb0/0x134
> [ 2294.616369]  [<ffffffff8105d7a5>] ? sched_clock+0x9/0xb
> [ 2294.616369]  [<ffffffff8187d929>] ? virtqueue_add+0x78/0x37f
> [ 2294.616369]  [<ffffffff8187d929>] virtqueue_add+0x78/0x37f
> [ 2294.616369]  [<ffffffff81114f72>] ? __lock_acquire+0x751/0xf55
> [ 2294.616369]  [<ffffffff8187dca6>] virtqueue_add_sgs+0x76/0x85
>
> The patch you are referring shouldn't make any change in this path
> because alloc_indirect which I expect is the allocation failing here
> does:
> gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH)
>
> and that came in via b92b1b89a33c ("virtio: force vring descriptors to
> be allocated from lowmem").
>
> Are there more failed allocations during the test? The subject would
> suggest so.

We done 24 tests for the commit and 24 tests for its parent.  There is
no OOM in any test for the parent commit, but there are OOM in 21 tests
for this commit.  This is what I want to say in the subject.  Sorry for
confusing.

Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/