From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751464AbbHEHy6 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 5 Aug 2015 03:54:58 -0400
Received: from szxga01-in.huawei.com ([58.251.152.64]:14249 "EHLO
	szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750881AbbHEHy5 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 5 Aug 2015 03:54:57 -0400
Message-ID: <55C1C132.2010805@huawei.com>
Date: Wed, 5 Aug 2015 15:54:26 +0800
From: Xishi Qiu <qiuxishi@huawei.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Dave Hansen <dave.hansen@intel.com>
CC: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@suse.de>,
        Vlastimil Babka <vbabka@suse.cz>, Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@suse.cz>, <iamjoonsoo.kim@lge.com>,
        <alexander.h.duyck@redhat.com>, <sasha.levin@oracle.com>,
        Linux MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: add the block to the tail of the list in expand()
References: <55BB4027.7080200@huawei.com> <55BC0392.2070205@intel.com> <55BECC85.7050206@huawei.com> <55BEE99E.8090901@intel.com> <55C011A6.1090003@huawei.com> <55C0CBC3.2000602@intel.com>
In-Reply-To: <55C0CBC3.2000602@intel.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.177.25.179]
X-CFilter-Loop: Reflected
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2015/8/4 22:27, Dave Hansen wrote:

> On 08/03/2015 06:13 PM, Xishi Qiu wrote:
>> How did you do the experiment?
> 
> I just stuck in some counters in expand() that looked to see whether the
> list was empty or not when the page is added and then printed them out
> occasionally.
> 

Hi Dave,

I add some debug code like this, but it doesn't trigger the dump_stack().

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -834,6 +834,12 @@ static inline void expand(struct zone *zone, struct page *page,
                        continue;
                }
 #endif
+
+         if (!list_empty(&area->free_list[migratetype])) {
+                 printk("expand(), the list is not empty\n");
+                 dump_stack();
+         }
+
                list_add(&page[size].lru, &area->free_list[migratetype]);
                area->nr_free++;
                set_page_order(&page[size], high);


> It will be interesting to see the results both on a freshly-booted
> system and one that's reached relatively steady-state and is moving
> around a minimal number of pageblocks between the different types.
> 
> In any case, the end result here needs to be some indication that the
> patch either helps ease fragmentation or helps performance.
> 
> .
>