All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: David Rientjes <rientjes@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 7/7] Do not compact within a preferred zone after a compaction failure
Date: Wed, 20 Jan 2010 09:51:48 +0000	[thread overview]
Message-ID: <20100120095148.GE5154@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.2.00.1001131527050.18951@chino.kir.corp.google.com>

On Wed, Jan 13, 2010 at 03:28:16PM -0800, David Rientjes wrote:
> On Wed, 6 Jan 2010, Mel Gorman wrote:
> 
> > The fragmentation index may indicate that a failure it due to external
> > fragmentation, a compaction run complete and an allocation failure still
> > fail. There are two obvious reasons as to why
> > 
> >   o Page migration cannot move all pages so fragmentation remains
> >   o A suitable page may exist but watermarks are not met
> > 
> > In the event of compaction and allocation failure, this patch prevents
> > compaction happening for a short interval. It's only recorded on the
> > preferred zone but that should be enough coverage. This could have been
> > implemented similar to the zonelist_cache but the increased size of the
> > zonelist did not appear to be justified.
> > 
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > ---
> >  include/linux/mmzone.h |    7 +++++++
> >  mm/page_alloc.c        |   15 ++++++++++++++-
> >  2 files changed, 21 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 30fe668..1d6ccbe 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -328,6 +328,13 @@ struct zone {
> >  	unsigned long		*pageblock_flags;
> >  #endif /* CONFIG_SPARSEMEM */
> >  
> > +#ifdef CONFIG_MIGRATION
> > +	/*
> > +	 * If a compaction fails, do not try compaction again until
> > +	 * jiffies is after the value of compact_resume
> > +	 */
> > +	unsigned long		compact_resume;
> > +#endif
> 
> CONFIG_COMPACTION?
> 

Yep

> >  
> >  	ZONE_PADDING(_pad1_)
> >  
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 7275afb..9c86606 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1729,7 +1729,7 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
> >  	cond_resched();
> >  
> >  	/* Try memory compaction for high-order allocations before reclaim */
> > -	if (order) {
> > +	if (order && time_after(jiffies, preferred_zone->compact_resume)) {
> >  		*did_some_progress = try_to_compact_pages(zonelist,
> >  						order, gfp_mask, nodemask);
> >  		if (*did_some_progress != COMPACT_INCOMPLETE) {
> > @@ -1748,6 +1748,19 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
> >  			 * but not enough to satisfy watermarks.
> >  			 */
> >  			count_vm_event(COMPACTFAIL);
> > +
> > +			/*
> > +			 * On failure, avoid compaction for a short time.
> > +			 * XXX: This is very unsatisfactory. The failure
> > +			 * 	to compact has nothing to do with time
> > +			 * 	and everything to do with the requested
> > +			 * 	order, the number of free pages and
> > +			 * 	watermarks. How to wait on that is more
> > +			 * 	unclear, but the answer would apply to
> > +			 * 	other areas where the VM waits based on
> > +			 * 	time.
> > +			 */
> > +			preferred_zone->compact_resume = jiffies + HZ/50;
> >  		}
> >  	}
> >  
> 
> This will need to be moved to (another) inline function dependent on 
> CONFIG_COMPACTION since we don't have zone->compact_resume without it; 
> it's probably better to seperate the function out rather than add #ifdef's 
> within __alloc_pages_direct_reclaim().
> 

Moved to an inline called defer_compaction()

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: David Rientjes <rientjes@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 7/7] Do not compact within a preferred zone after a compaction failure
Date: Wed, 20 Jan 2010 09:51:48 +0000	[thread overview]
Message-ID: <20100120095148.GE5154@csn.ul.ie> (raw)
In-Reply-To: <alpine.DEB.2.00.1001131527050.18951@chino.kir.corp.google.com>

On Wed, Jan 13, 2010 at 03:28:16PM -0800, David Rientjes wrote:
> On Wed, 6 Jan 2010, Mel Gorman wrote:
> 
> > The fragmentation index may indicate that a failure it due to external
> > fragmentation, a compaction run complete and an allocation failure still
> > fail. There are two obvious reasons as to why
> > 
> >   o Page migration cannot move all pages so fragmentation remains
> >   o A suitable page may exist but watermarks are not met
> > 
> > In the event of compaction and allocation failure, this patch prevents
> > compaction happening for a short interval. It's only recorded on the
> > preferred zone but that should be enough coverage. This could have been
> > implemented similar to the zonelist_cache but the increased size of the
> > zonelist did not appear to be justified.
> > 
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > ---
> >  include/linux/mmzone.h |    7 +++++++
> >  mm/page_alloc.c        |   15 ++++++++++++++-
> >  2 files changed, 21 insertions(+), 1 deletions(-)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 30fe668..1d6ccbe 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -328,6 +328,13 @@ struct zone {
> >  	unsigned long		*pageblock_flags;
> >  #endif /* CONFIG_SPARSEMEM */
> >  
> > +#ifdef CONFIG_MIGRATION
> > +	/*
> > +	 * If a compaction fails, do not try compaction again until
> > +	 * jiffies is after the value of compact_resume
> > +	 */
> > +	unsigned long		compact_resume;
> > +#endif
> 
> CONFIG_COMPACTION?
> 

Yep

> >  
> >  	ZONE_PADDING(_pad1_)
> >  
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 7275afb..9c86606 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1729,7 +1729,7 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
> >  	cond_resched();
> >  
> >  	/* Try memory compaction for high-order allocations before reclaim */
> > -	if (order) {
> > +	if (order && time_after(jiffies, preferred_zone->compact_resume)) {
> >  		*did_some_progress = try_to_compact_pages(zonelist,
> >  						order, gfp_mask, nodemask);
> >  		if (*did_some_progress != COMPACT_INCOMPLETE) {
> > @@ -1748,6 +1748,19 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
> >  			 * but not enough to satisfy watermarks.
> >  			 */
> >  			count_vm_event(COMPACTFAIL);
> > +
> > +			/*
> > +			 * On failure, avoid compaction for a short time.
> > +			 * XXX: This is very unsatisfactory. The failure
> > +			 * 	to compact has nothing to do with time
> > +			 * 	and everything to do with the requested
> > +			 * 	order, the number of free pages and
> > +			 * 	watermarks. How to wait on that is more
> > +			 * 	unclear, but the answer would apply to
> > +			 * 	other areas where the VM waits based on
> > +			 * 	time.
> > +			 */
> > +			preferred_zone->compact_resume = jiffies + HZ/50;
> >  		}
> >  	}
> >  
> 
> This will need to be moved to (another) inline function dependent on 
> CONFIG_COMPACTION since we don't have zone->compact_resume without it; 
> it's probably better to seperate the function out rather than add #ifdef's 
> within __alloc_pages_direct_reclaim().
> 

Moved to an inline called defer_compaction()

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

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

  reply	other threads:[~2010-01-20  9:52 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-06 16:26 [RFC-PATCH 0/7] Memory Compaction v1 Mel Gorman
2010-01-06 16:26 ` Mel Gorman
2010-01-06 16:26 ` [PATCH 1/7] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-07 21:46   ` David Rientjes
2010-01-07 21:46     ` David Rientjes
2010-01-07 22:04     ` Christoph Lameter
2010-01-07 22:04       ` Christoph Lameter
2010-01-19 13:00     ` Mel Gorman
2010-01-19 13:00       ` Mel Gorman
2010-01-06 16:26 ` [PATCH 2/7] Export unusable free space index via /proc/pagetypeinfo Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 17:10   ` Adam Litke
2010-01-06 17:10     ` Adam Litke
2010-01-06 17:29     ` Mel Gorman
2010-01-06 17:29       ` Mel Gorman
2010-01-06 23:21   ` Tim Pepper
2010-01-06 23:21     ` Tim Pepper
2010-01-28 22:27   ` David Rientjes
2010-01-28 22:27     ` David Rientjes
2010-02-05 10:23     ` Mel Gorman
2010-02-05 10:23       ` Mel Gorman
2010-02-05 21:40       ` David Rientjes
2010-02-05 21:40         ` David Rientjes
2010-02-08 12:10         ` Mel Gorman
2010-02-08 12:10           ` Mel Gorman
2010-01-06 16:26 ` [PATCH 3/7] Export fragmentation " Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 16:26 ` [PATCH 4/7] Memory compaction core Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 17:50   ` Mel Gorman
2010-01-06 17:50     ` Mel Gorman
2010-01-06 18:22     ` Mel Gorman
2010-01-06 18:22       ` Mel Gorman
2010-01-06 21:37   ` Andi Kleen
2010-01-06 21:37     ` Andi Kleen
2010-01-06 22:07     ` Mel Gorman
2010-01-06 22:07       ` Mel Gorman
2010-01-06 16:26 ` [PATCH 5/7] Add /proc trigger for memory compaction Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-07 22:00   ` David Rientjes
2010-01-07 22:00     ` David Rientjes
2010-01-13 23:23     ` David Rientjes
2010-01-13 23:23       ` David Rientjes
2010-01-20  9:48       ` Mel Gorman
2010-01-20  9:48         ` Mel Gorman
2010-01-20  9:48     ` Mel Gorman
2010-01-20  9:48       ` Mel Gorman
2010-01-20 18:12       ` Christoph Lameter
2010-01-20 18:12         ` Christoph Lameter
2010-01-20 20:53         ` Mel Gorman
2010-01-20 20:53           ` Mel Gorman
2010-01-20 20:48       ` David Rientjes
2010-01-20 20:48         ` David Rientjes
2010-01-21 14:09         ` Mel Gorman
2010-01-21 14:09           ` Mel Gorman
2010-01-21 23:34           ` David Rientjes
2010-01-21 23:34             ` David Rientjes
2010-01-06 16:26 ` [PATCH 6/7] Direct compact when a high-order allocation fails Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-06 16:26 ` [PATCH 7/7] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-01-06 16:26   ` Mel Gorman
2010-01-13 23:28   ` David Rientjes
2010-01-13 23:28     ` David Rientjes
2010-01-20  9:51     ` Mel Gorman [this message]
2010-01-20  9:51       ` Mel Gorman
2010-01-21  3:12 ` [RFC-PATCH 0/7] Memory Compaction v1 KOSAKI Motohiro
2010-01-21  3:12   ` KOSAKI Motohiro
2010-01-21 10:11   ` Mel Gorman
2010-01-21 10:11     ` Mel Gorman
2010-01-22  0:16     ` KOSAKI Motohiro
2010-01-22  0:16       ` KOSAKI Motohiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100120095148.GE5154@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=aarcange@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.