Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755769Ab0LIPnN (ORCPT ); Thu, 9 Dec 2010 10:43:13 -0500 Received: from mail-pw0-f46.google.com ([209.85.160.46]:61714 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755599Ab0LIPnJ (ORCPT ); Thu, 9 Dec 2010 10:43:09 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aJu9n4IBAweIBfanUg9YdN7JPyHX2Py432uCutj68O2ePwzID2muk5uQIK9is+njaZ 0aU4rS2axoC9c3Rmh8bUDc4h0czpNo4Uaa/MJcl5cUdywE2MSYB+gL0/nV4VTCnlHswK HJJh+5pH9Ace+DPDrNf+P58DLocHBvPpmrRy8= Date: Fri, 10 Dec 2010 00:42:58 +0900 From: Minchan Kim To: Mel Gorman Cc: Simon Kirby , KOSAKI Motohiro , Shaohua Li , Dave Hansen , Johannes Weiner , Andrew Morton , linux-mm , linux-kernel Subject: Re: [PATCH 2/6] mm: kswapd: Keep kswapd awake for high-order allocations until a percentage of the node is balanced Message-ID: <20101209154258.GC1740@barrios-desktop> References: <1291893500-12342-1-git-send-email-mel@csn.ul.ie> <1291893500-12342-3-git-send-email-mel@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291893500-12342-3-git-send-email-mel@csn.ul.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5083 Lines: 151 On Thu, Dec 09, 2010 at 11:18:16AM +0000, Mel Gorman wrote: > When reclaiming for high-orders, kswapd is responsible for balancing a > node but it should not reclaim excessively. It avoids excessive reclaim by > considering if any zone in a node is balanced then the node is balanced. In > the cases where there are imbalanced zone sizes (e.g. ZONE_DMA with both > ZONE_DMA32 and ZONE_NORMAL), kswapd can go to sleep prematurely as just > one small zone was balanced. > > This alters the sleep logic of kswapd slightly. It counts the number of pages > that make up the balanced zones. If the total number of balanced pages is > more than a quarter of the zone, kswapd will go back to sleep. This should > keep a node balanced without reclaiming an excessive number of pages. > > Signed-off-by: Mel Gorman Reviewed-by: Minchan Kim Just below trivials. > --- > mm/vmscan.c | 43 ++++++++++++++++++++++++++++++++++--------- > 1 files changed, 34 insertions(+), 9 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 25cb373..b4472a1 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2117,10 +2117,26 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *mem_cont, > } > #endif > > +/* > + * pgdat_balanced is used when checking if a node is balanced for high-order > + * allocations. Only zones that meet watermarks make up "balanced". > + * The total of balanced pages must be at least 25% of the node for the Could you write down why you select 25% in description? It could help someone who try to change that watermark in future. > + * node to be considered balanced. Forcing all zones to be balanced for high > + * orders can cause excessive reclaim when there are imbalanced zones. > + * Similarly, we do not want kswapd to go to sleep because ZONE_DMA happens > + * to be balanced when ZONE_DMA32 is huge in comparison and unbalanced > + */ > +static bool pgdat_balanced(pg_data_t *pgdat, unsigned long balanced) I think balanced_pages is more clear. But it's a preference. > +{ > + return balanced > pgdat->node_present_pages / 4; > +} > + > /* is kswapd sleeping prematurely? */ > static int sleeping_prematurely(pg_data_t *pgdat, int order, long remaining) > { > int i; > + unsigned long balanced = 0; > + bool all_zones_ok = true; > > /* If a direct reclaimer woke kswapd within HZ/10, it's premature */ > if (remaining) > @@ -2138,10 +2154,19 @@ static int sleeping_prematurely(pg_data_t *pgdat, int order, long remaining) > > if (!zone_watermark_ok(zone, order, high_wmark_pages(zone), > 0, 0)) > - return 1; > + all_zones_ok = false; > + else > + balanced += zone->present_pages; > } > > - return 0; > + /* > + * For high-order requests, any zone meeting the watermark allows > + * kswapd to sleep. For order-0, all zones must be balanced The comment isn't exact. could allow? > + */ > + if (order) > + return pgdat_balanced(pgdat, balanced); > + else > + return !all_zones_ok; > } > > /* > @@ -2169,7 +2194,7 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order, > int classzone_idx) > { > int all_zones_ok; > - int any_zone_ok; > + unsigned long balanced; > int priority; > int i; > int end_zone = 0; /* Inclusive. 0 = ZONE_DMA */ > @@ -2203,7 +2228,7 @@ loop_again: > disable_swap_token(); > > all_zones_ok = 1; > - any_zone_ok = 0; > + balanced = 0; > > /* > * Scan in the highmem->dma direction for the highest > @@ -2314,11 +2339,11 @@ loop_again: > */ > zone_clear_flag(zone, ZONE_CONGESTED); > if (i <= classzone_idx) > - any_zone_ok = 1; > + balanced += zone->present_pages; > } > > } > - if (all_zones_ok || (order && any_zone_ok)) > + if (all_zones_ok || (order && pgdat_balanced(pgdat, balanced))) > break; /* kswapd: all done */ > /* > * OK, kswapd is getting into trouble. Take a nap, then take > @@ -2344,10 +2369,10 @@ out: > > /* > * order-0: All zones must meet high watermark for a balanced node > - * high-order: Any zone below pgdats classzone_idx must meet the high > - * watermark for a balanced node > + * high-order: Balanced zones must make up at least 25% of the node > + * for the node to be balanced > */ > - if (!(all_zones_ok || (order && any_zone_ok))) { > + if (!(all_zones_ok || (order && pgdat_balanced(pgdat, balanced)))) { > cond_resched(); > > try_to_freeze(); > -- > 1.7.1 > > -- > 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/ . > Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ > Don't email: email@kvack.org -- 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/