From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752265AbbCXBYw (ORCPT ); Mon, 23 Mar 2015 21:24:52 -0400 Received: from LGEMRELSE7Q.lge.com ([156.147.1.151]:58968 "EHLO lgemrelse7q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbbCXBYv (ORCPT ); Mon, 23 Mar 2015 21:24:51 -0400 X-Original-SENDERIP: 10.178.37.108 X-Original-MAILFROM: gioh.kim@lge.com Message-ID: <5510BCAC.5010101@lge.com> Date: Tue, 24 Mar 2015 10:23:56 +0900 From: Gioh Kim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Rientjes CC: akpm@linux-foundation.org, vbabka@suse.cz, iamjoonsoo.kim@lge.com, mgorman@suse.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org, gunho.lee@lge.com, Gioh Kim Subject: Re: [PATCH] mm/compaction: reset compaction scanner positions References: <1426939106-30347-1-git-send-email-gioh.kim@lge.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2015-03-24 오전 8:16에 David Rientjes 이(가) 쓴 글: > On Sat, 21 Mar 2015, Gioh Kim wrote: > >> When the compaction is activated via /proc/sys/vm/compact_memory >> it would better scan the whole zone. >> And some platform, for instance ARM, has the start_pfn of a zone is zero. >> Therefore the first try to compaction via /proc doesn't work. >> It needs to force to reset compaction scanner position at first. >> >> Signed-off-by: Gioh Kim > > That shouldn't be a valid email address. It's my fault. I'm going to send patch again. > >> Acked-by: Vlastimil Babka > > Acked-by: David Rientjes > > I was thinking that maybe this would be better handled as part of the > comapct_zone() logic, i.e. set cc->free_pfn and cc->migrate_pfn based on a > helper function that understands cc->order == -1 should compact the entire > zone. However, after scanning the entire zone as a result of this write, > the existing cached pfns probably don't matter anymore. So this seems > fine. >