Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752701Ab2FKXXo (ORCPT <rfc822;w@1wt.eu>);
	Mon, 11 Jun 2012 19:23:44 -0400
Received: from LGEMRELSE6Q.lge.com ([156.147.1.121]:62787 "EHLO
	LGEMRELSE6Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751664Ab2FKXXn (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 11 Jun 2012 19:23:43 -0400
X-AuditID: 9c930179-b7bb9ae000000ea5-48-4fd67dfddba3
Message-ID: <4FD67E00.4040700@kernel.org>
Date: Tue, 12 Jun 2012 08:23:44 +0900
From: Minchan Kim <minchan@kernel.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
Newsgroups: gmane.linux.kernel.mm,gmane.linux.kernel
To: Andrew Morton <akpm@linux-foundation.org>
CC: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@suse.cz>,
        KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] mm: clean up __count_immobile_pages
References: <1339380442-1137-1-git-send-email-minchan@kernel.org> <20120611144011.60fd76c8.akpm@linux-foundation.org>
In-Reply-To: <20120611144011.60fd76c8.akpm@linux-foundation.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2677
Lines: 72

On 06/12/2012 06:40 AM, Andrew Morton wrote:

> On Mon, 11 Jun 2012 11:07:22 +0900
> Minchan Kim <minchan@kernel.org> wrote:
> 
>> __count_immobile_pages naming is rather awkward.
>> This patch clean up the function and add comment.
> 
> This conflicts with
> mm-compaction-handle-incorrect-migrate_unmovable-type-pageblocks.patch
> and its fixes.


I wanted to revert [1] and friends and merge again based on [2] and this patch.
Because [1] has still bug I explained in [2]. If it is merged without [2], it simply can
spread bug from one place(memory hotplug) to two place(memory hotplug and compaction).

We discussed real effectiveness of [1] because the patch is rather complicated than
expectation. I don't want to add unnecessary maintain cost if it doesn't have proved benefit.

KOSAKI and me : doesn't want to merge without proving (https://lkml.org/lkml/2012/6/5/3)
Mel: Pass the decision to CMA guys (https://lkml.org/lkml/2012/6/11/242)
Rik: want to test it based on THP alloc ratio (https://lkml.org/lkml/2012/6/11/293)

I guess anyone has no sure for needing it, at least.

Even, [1] added new vmstat "compact_rescued_unmovable_blocks". 
Why I firstly suggest is just for the proving the effectiveness easily and wanted to
revert the vmstat later before merging mainline if we prove it.
(But it seems that KOSAKI doesn't like it - https://lkml.org/lkml/2012/6/5/282)
But now Bartlomiej want to maintain it permanently in vmstat.
IMHO, it's not a good idea.
Anyway, adding new vmstat part should be careful and get a agreement from mm guys.

[1] mm-compaction-handle-incorrect-migrate_unmovable-type-pageblocks.patch
[2] [PATCH] mm: do not use page_count without a page pin

> 
>> + * This function can race in PageLRU and MIGRATE_MOVABLE can have unmovable
>> + * pages so that it might be not exact.
> 
> I don't understand this.  Functions race against other functions, not
> against a page flag.  Can we have another attempt at this description


You're right. I meant page flags.

> please?


Before that, I would like to clear out how you handle this patch dependencies.
What should I do? 
Any tree and any patchset based on for the work?

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



-- 
Kind regards,
Minchan Kim
--
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/