From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755669Ab2HHBq5 (ORCPT ); Tue, 7 Aug 2012 21:46:57 -0400 Received: from LGEMRELSE1Q.lge.com ([156.147.1.111]:42666 "EHLO LGEMRELSE1Q.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755229Ab2HHBqz (ORCPT ); Tue, 7 Aug 2012 21:46:55 -0400 X-AuditID: 9c93016f-b7b08ae00000790d-b8-5021c50c031c Date: Wed, 8 Aug 2012 10:48:24 +0900 From: Minchan Kim To: Mel Gorman Cc: Linux-MM , Rik van Riel , Jim Schutt , LKML Subject: Re: [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Message-ID: <20120808014824.GB4247@bbox> References: <1344342677-5845-1-git-send-email-mgorman@suse.de> <1344342677-5845-3-git-send-email-mgorman@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1344342677-5845-3-git-send-email-mgorman@suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mel, Just out of curiosity. What's the problem did you see? (ie, What's the problem do this patch solve?) AFAIUC, it seem to solve consecutive allocation success ratio through getting several free pageblocks all at once in a process/kswapd reclaim context. Right? On Tue, Aug 07, 2012 at 01:31:13PM +0100, Mel Gorman wrote: > If allocation fails after compaction then compaction may be deferred for > a number of allocation attempts. If there are subsequent failures, > compact_defer_shift is increased to defer for longer periods. This patch > uses that information to scale the number of pages reclaimed with > compact_defer_shift until allocations succeed again. > > Signed-off-by: Mel Gorman > --- > mm/vmscan.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 66e4310..0cb2593 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1708,6 +1708,7 @@ static inline bool should_continue_reclaim(struct lruvec *lruvec, > { > unsigned long pages_for_compaction; > unsigned long inactive_lru_pages; > + struct zone *zone; > > /* If not in reclaim/compaction mode, stop */ > if (!in_reclaim_compaction(sc)) > @@ -1741,6 +1742,15 @@ static inline bool should_continue_reclaim(struct lruvec *lruvec, > * inactive lists are large enough, continue reclaiming > */ > pages_for_compaction = (2UL << sc->order); > + > + /* > + * If compaction is deferred for this order then scale the number of > + * pages reclaimed based on the number of consecutive allocation > + * failures > + */ > + zone = lruvec_zone(lruvec); > + if (zone->compact_order_failed >= sc->order) > + pages_for_compaction <<= zone->compact_defer_shift; > inactive_lru_pages = get_lru_size(lruvec, LRU_INACTIVE_FILE); > if (nr_swap_pages > 0) > inactive_lru_pages += get_lru_size(lruvec, LRU_INACTIVE_ANON); > -- > 1.7.9.2 > > -- > 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: email@kvack.org -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx202.postini.com [74.125.245.202]) by kanga.kvack.org (Postfix) with SMTP id 4DE876B004D for ; Tue, 7 Aug 2012 21:46:54 -0400 (EDT) Date: Wed, 8 Aug 2012 10:48:24 +0900 From: Minchan Kim Subject: Re: [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Message-ID: <20120808014824.GB4247@bbox> References: <1344342677-5845-1-git-send-email-mgorman@suse.de> <1344342677-5845-3-git-send-email-mgorman@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1344342677-5845-3-git-send-email-mgorman@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Linux-MM , Rik van Riel , Jim Schutt , LKML Hi Mel, Just out of curiosity. What's the problem did you see? (ie, What's the problem do this patch solve?) AFAIUC, it seem to solve consecutive allocation success ratio through getting several free pageblocks all at once in a process/kswapd reclaim context. Right? On Tue, Aug 07, 2012 at 01:31:13PM +0100, Mel Gorman wrote: > If allocation fails after compaction then compaction may be deferred for > a number of allocation attempts. If there are subsequent failures, > compact_defer_shift is increased to defer for longer periods. This patch > uses that information to scale the number of pages reclaimed with > compact_defer_shift until allocations succeed again. > > Signed-off-by: Mel Gorman > --- > mm/vmscan.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 66e4310..0cb2593 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1708,6 +1708,7 @@ static inline bool should_continue_reclaim(struct lruvec *lruvec, > { > unsigned long pages_for_compaction; > unsigned long inactive_lru_pages; > + struct zone *zone; > > /* If not in reclaim/compaction mode, stop */ > if (!in_reclaim_compaction(sc)) > @@ -1741,6 +1742,15 @@ static inline bool should_continue_reclaim(struct lruvec *lruvec, > * inactive lists are large enough, continue reclaiming > */ > pages_for_compaction = (2UL << sc->order); > + > + /* > + * If compaction is deferred for this order then scale the number of > + * pages reclaimed based on the number of consecutive allocation > + * failures > + */ > + zone = lruvec_zone(lruvec); > + if (zone->compact_order_failed >= sc->order) > + pages_for_compaction <<= zone->compact_defer_shift; > inactive_lru_pages = get_lru_size(lruvec, LRU_INACTIVE_FILE); > if (nr_swap_pages > 0) > inactive_lru_pages += get_lru_size(lruvec, LRU_INACTIVE_ANON); > -- > 1.7.9.2 > > -- > 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: email@kvack.org -- Kind regards, Minchan Kim -- 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: email@kvack.org