From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751781AbcGFBZK (ORCPT ); Tue, 5 Jul 2016 21:25:10 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:53728 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbcGFBZH (ORCPT ); Tue, 5 Jul 2016 21:25:07 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Wed, 6 Jul 2016 10:25:54 +0900 From: Minchan Kim To: Mel Gorman Cc: Andrew Morton , Linux-MM , Rik van Riel , Vlastimil Babka , Johannes Weiner , LKML Subject: Re: [PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone Message-ID: <20160706012554.GD12570@bbox> References: <1467403299-25786-1-git-send-email-mgorman@techsingularity.net> <1467403299-25786-12-git-send-email-mgorman@techsingularity.net> <20160705061117.GD28164@bbox> <20160705103806.GH11498@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160705103806.GH11498@techsingularity.net> 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 On Tue, Jul 05, 2016 at 11:38:06AM +0100, Mel Gorman wrote: > On Tue, Jul 05, 2016 at 03:11:17PM +0900, Minchan Kim wrote: > > > - if (i < 0) > > > - goto out; > > > + /* > > > + * Only reclaim if there are no eligible zones. Check from > > > + * high to low zone to avoid prematurely clearing pgdat > > > + * congested state. > > > > I cannot understand "prematurely clearing pgdat congested state". > > Could you add more words to clear it out? > > > > It's surprisingly difficult to concisely explain. Is this any better? > > /* > * Only reclaim if there are no eligible zones. Check from > * high to low zone as allocations prefer higher zones. > * Scanning from low to high zone would allow congestion to be > * cleared during a very small window when a small low > * zone was balanced even under extreme pressure when the > * overall node may be congested. > */ Surely, it's better. Thanks for the explaining. I doubt we need such corner case logic at this moment and how it works well without consistent scan from other callers of zone_balanced where scans from low to high. > > > + */ > > > + for (i = classzone_idx; i >= 0; i--) { > > > + zone = pgdat->node_zones + i; > > > + if (!populated_zone(zone)) > > > + continue; > > > + > > > + if (zone_balanced(zone, sc.order, classzone_idx)) > > > > If buffer_head is over limit, old logic force to reclaim highmem but > > this zone_balanced logic will prevent it. > > > > The old logic was always busted on 64-bit because is_highmem would always > be 0. The original intent appears to be that buffer_heads_over_limit > would release the buffers when pages went inactive. There are a number Yes but the difference is in old, it was handled both direct and background reclaim once buffers_heads is over the limit but your change slightly changs it so kswapd couldn't reclaim high zone if any eligible zone is balanced. I don't know how big difference it can make but we saw highmem buffer_head problems several times, IIRC. So, I just wanted to notice it to you. whether it's handled or not, it's up to you. > of things we treated inconsistently that get fixed up in the series and > buffer_heads_over_limit is one of them. > > -- > Mel Gorman > SUSE Labs > > -- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f199.google.com (mail-ob0-f199.google.com [209.85.214.199]) by kanga.kvack.org (Postfix) with ESMTP id 8D40A828E1 for ; Tue, 5 Jul 2016 21:25:05 -0400 (EDT) Received: by mail-ob0-f199.google.com with SMTP id fq2so460073398obb.2 for ; Tue, 05 Jul 2016 18:25:05 -0700 (PDT) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTP id z64si852080itd.81.2016.07.05.18.25.04 for ; Tue, 05 Jul 2016 18:25:04 -0700 (PDT) Date: Wed, 6 Jul 2016 10:25:54 +0900 From: Minchan Kim Subject: Re: [PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone Message-ID: <20160706012554.GD12570@bbox> References: <1467403299-25786-1-git-send-email-mgorman@techsingularity.net> <1467403299-25786-12-git-send-email-mgorman@techsingularity.net> <20160705061117.GD28164@bbox> <20160705103806.GH11498@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160705103806.GH11498@techsingularity.net> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Andrew Morton , Linux-MM , Rik van Riel , Vlastimil Babka , Johannes Weiner , LKML On Tue, Jul 05, 2016 at 11:38:06AM +0100, Mel Gorman wrote: > On Tue, Jul 05, 2016 at 03:11:17PM +0900, Minchan Kim wrote: > > > - if (i < 0) > > > - goto out; > > > + /* > > > + * Only reclaim if there are no eligible zones. Check from > > > + * high to low zone to avoid prematurely clearing pgdat > > > + * congested state. > > > > I cannot understand "prematurely clearing pgdat congested state". > > Could you add more words to clear it out? > > > > It's surprisingly difficult to concisely explain. Is this any better? > > /* > * Only reclaim if there are no eligible zones. Check from > * high to low zone as allocations prefer higher zones. > * Scanning from low to high zone would allow congestion to be > * cleared during a very small window when a small low > * zone was balanced even under extreme pressure when the > * overall node may be congested. > */ Surely, it's better. Thanks for the explaining. I doubt we need such corner case logic at this moment and how it works well without consistent scan from other callers of zone_balanced where scans from low to high. > > > + */ > > > + for (i = classzone_idx; i >= 0; i--) { > > > + zone = pgdat->node_zones + i; > > > + if (!populated_zone(zone)) > > > + continue; > > > + > > > + if (zone_balanced(zone, sc.order, classzone_idx)) > > > > If buffer_head is over limit, old logic force to reclaim highmem but > > this zone_balanced logic will prevent it. > > > > The old logic was always busted on 64-bit because is_highmem would always > be 0. The original intent appears to be that buffer_heads_over_limit > would release the buffers when pages went inactive. There are a number Yes but the difference is in old, it was handled both direct and background reclaim once buffers_heads is over the limit but your change slightly changs it so kswapd couldn't reclaim high zone if any eligible zone is balanced. I don't know how big difference it can make but we saw highmem buffer_head problems several times, IIRC. So, I just wanted to notice it to you. whether it's handled or not, it's up to you. > of things we treated inconsistently that get fixed up in the series and > buffer_heads_over_limit is one of them. > > -- > Mel Gorman > SUSE Labs > > -- > 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 -- 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