Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752474Ab3CUSOD (ORCPT ); Thu, 21 Mar 2013 14:14:03 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45447 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752426Ab3CUSOA (ORCPT ); Thu, 21 Mar 2013 14:14:00 -0400 Date: Thu, 21 Mar 2013 18:13:56 +0000 From: Mel Gorman To: Michal Hocko Cc: Linux-MM , Jiri Slaby , Valdis Kletnieks , Rik van Riel , Zlatko Calusic , Johannes Weiner , dormando , Satoru Moriya , LKML Subject: Re: [PATCH 10/10] mm: vmscan: Move logic from balance_pgdat() to kswapd_shrink_zone() Message-ID: <20130321181356.GO1878@suse.de> References: <1363525456-10448-1-git-send-email-mgorman@suse.de> <1363525456-10448-11-git-send-email-mgorman@suse.de> <20130321171804.GW6094@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20130321171804.GW6094@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5428 Lines: 150 On Thu, Mar 21, 2013 at 06:18:04PM +0100, Michal Hocko wrote: > On Sun 17-03-13 13:04:16, Mel Gorman wrote: > > + > > + /* > > + * Kswapd reclaims only single pages with compaction enabled. Trying > > + * too hard to reclaim until contiguous free pages have become > > + * available can hurt performance by evicting too much useful data > > + * from memory. Do not reclaim more than needed for compaction. > > + */ > > + if (IS_ENABLED(CONFIG_COMPACTION) && sc->order && > > + compaction_suitable(zone, sc->order) != > > + COMPACT_SKIPPED) > > + testorder = 0; > > + > > + /* > > + * We put equal pressure on every zone, unless one zone has way too > > + * many pages free already. The "too many pages" is defined as the > > + * high wmark plus a "gap" where the gap is either the low > > + * watermark or 1% of the zone, whichever is smaller. > > + */ > > + balance_gap = min(low_wmark_pages(zone), > > + (zone->managed_pages + KSWAPD_ZONE_BALANCE_GAP_RATIO-1) / > > + KSWAPD_ZONE_BALANCE_GAP_RATIO); > > + > > + /* > > + * If there is no low memory pressure or the zone is balanced then no > > + * reclaim is necessary > > + */ > > + lowmem_pressure = (buffer_heads_over_limit && is_highmem(zone)); > > + if (!(lowmem_pressure || !zone_balanced(zone, testorder, > > + balance_gap, classzone_idx))) > > if (!lowmem_pressure && zone_balanced) would be less cryptic I guess > It would. > > + return true; > > + > > shrink_zone(zone, sc); > > > > /* > > @@ -2689,6 +2724,16 @@ static bool kswapd_shrink_zone(struct zone *zone, > > > > zone_clear_flag(zone, ZONE_WRITEBACK); > > > > + /* > > + * If a zone reaches its high watermark, consider it to be no longer > > + * congested. It's possible there are dirty pages backed by congested > > + * BDIs but as pressure is relieved, speculatively avoid congestion > > + * waits. > > + */ > > + if (!zone->all_unreclaimable && > > + zone_balanced(zone, testorder, 0, classzone_idx)) > > + zone_clear_flag(zone, ZONE_CONGESTED); > > + > > return sc->nr_scanned >= sc->nr_to_reclaim; > > } > > > > @@ -2821,8 +2866,6 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order, > > */ > > for (i = 0; i <= end_zone; i++) { > > struct zone *zone = pgdat->node_zones + i; > > - int testorder; > > - unsigned long balance_gap; > > > > if (!populated_zone(zone)) > > continue; > > @@ -2843,61 +2886,16 @@ static unsigned long balance_pgdat(pg_data_t *pgdat, int order, > > sc.nr_reclaimed += nr_soft_reclaimed; > > > > /* > > - * We put equal pressure on every zone, unless > > - * one zone has way too many pages free > > - * already. The "too many pages" is defined > > - * as the high wmark plus a "gap" where the > > - * gap is either the low watermark or 1% > > - * of the zone, whichever is smaller. > > - */ > > - balance_gap = min(low_wmark_pages(zone), > > - (zone->managed_pages + > > - KSWAPD_ZONE_BALANCE_GAP_RATIO-1) / > > - KSWAPD_ZONE_BALANCE_GAP_RATIO); > > - /* > > - * Kswapd reclaims only single pages with compaction > > - * enabled. Trying too hard to reclaim until contiguous > > - * free pages have become available can hurt performance > > - * by evicting too much useful data from memory. > > - * Do not reclaim more than needed for compaction. > > + * There should be no need to raise the scanning > > + * priority if enough pages are already being scanned > > + * that that high watermark would be met at 100% > > + * efficiency. > > */ > > - testorder = order; > > - if (IS_ENABLED(CONFIG_COMPACTION) && order && > > - compaction_suitable(zone, order) != > > - COMPACT_SKIPPED) > > - testorder = 0; > > - > > - if ((buffer_heads_over_limit && is_highmem_idx(i)) || > > - !zone_balanced(zone, testorder, > > - balance_gap, end_zone)) { > > - /* > > - * There should be no need to raise the > > - * scanning priority if enough pages are > > - * already being scanned that that high > > - * watermark would be met at 100% efficiency. > > - */ > > - if (kswapd_shrink_zone(zone, &sc, > > + if (kswapd_shrink_zone(zone, end_zone, &sc, > > lru_pages, shrinking_slab)) > > raise_priority = false; > > > > - nr_to_reclaim += sc.nr_to_reclaim; > > - } > > - > > - if (zone->all_unreclaimable) { > > - if (end_zone && end_zone == i) > > - end_zone--; > > - continue; > > - } > > - > > - if (zone_balanced(zone, testorder, 0, end_zone)) > > - /* > > - * If a zone reaches its high watermark, > > - * consider it to be no longer congested. It's > > - * possible there are dirty pages backed by > > - * congested BDIs but as pressure is relieved, > > - * speculatively avoid congestion waits > > - */ > > - zone_clear_flag(zone, ZONE_CONGESTED); > > + nr_to_reclaim += sc.nr_to_reclaim; > > } > > nr_to_reclaim is updated if the zone is balanced an no reclaim is done > which break compaction condition AFAICS. > True, it only makes sense to account for the pages it actually attempted to reclaim. Thanks. -- Mel Gorman SUSE Labs -- 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/