Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5779758ybv; Tue, 11 Feb 2020 23:45:32 -0800 (PST) X-Google-Smtp-Source: APXvYqwlhHdX2dMRMPOTZvnogZwClw2TmxuI25OpXkYOqTRpnvUDjGN/lYoVviEnT/AHUNmasIdB X-Received: by 2002:a9d:674f:: with SMTP id w15mr8231558otm.243.1581493532171; Tue, 11 Feb 2020 23:45:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581493532; cv=none; d=google.com; s=arc-20160816; b=jUo/hhrKehhT1xB/uPQsfjZ2BzkZjrkixcHbAF7kidD2ZtulcPdnxRqpz+ABeXYx/+ 6XXrr5cQGA/wyL4RVeg0MqLCN1ZxB4jfVDsxQmu+IDxViKqe34LZQi4AHWb07g2Lv8Pk 8UGJIQD4FFPFdCPEZ+elX5W7xc+ZQ8uIv1A7q7Nk2ZmK3JadAyvOzQyMG3qHRTdGU4tZ 09RW0kx4PirrclezYf9kj3tM94+T2/D3sNbwGDnFuaAmrUKlf7AopEpnn/ffQG36h4uy ShdqDDWX92CzF0dUKBe4ctgpSf8nr9F82qnFXqGE66xDSx+Mo6xat3LMwv0KqdVnvMUR QR/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=SSLfCqpVz+SYZaesYPN4XdhFUuFryYKY6V0bS0op1xc=; b=K0B0z2H6Ep+mjYIrgrZgChE8HjeJ0IqHHypnY3r+ng+BddV0PAcZrRQzvTYMOz+1c7 pAJLGmB11nr/+8d7XWccXtipS9oQG8pVDHn6l461jNlnIaCiEpyY2CiGLqY1Tt3Xi4Ux tiQ4n3bgjtQCr6xrm0ZOZAdCYOpHY3Fq8ShjZ/a63WhWbZ2JFY+KROB4dtI3cGguxThW RuUxHJ7OQ6rsxTQL6vgULaTBsp5LmeYIb8EI8G1O//mM116bRAyg376OxOzIo+B03eAa udoSlNrmQy5ojNAJ7C1ni/yspkIXaktx9Y1k1o5J/tKRuoESFWAqIrmbXnMZH4d3BfBV iSNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i9si3257159otp.139.2020.02.11.23.45.18; Tue, 11 Feb 2020 23:45:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728353AbgBLHni (ORCPT + 99 others); Wed, 12 Feb 2020 02:43:38 -0500 Received: from outbound-smtp53.blacknight.com ([46.22.136.237]:43227 "EHLO outbound-smtp53.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727669AbgBLHni (ORCPT ); Wed, 12 Feb 2020 02:43:38 -0500 Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp53.blacknight.com (Postfix) with ESMTPS id 55DD3FAE23 for ; Wed, 12 Feb 2020 07:43:36 +0000 (GMT) Received: (qmail 4764 invoked from network); 12 Feb 2020 07:43:36 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.18.57]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 12 Feb 2020 07:43:35 -0000 Date: Wed, 12 Feb 2020 07:43:33 +0000 From: Mel Gorman To: Wei Yang Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, shakeelb@google.com, yang.shi@linux.alibaba.com Subject: Re: [RFC Patch] mm/vmscan.c: not inherit classzone_idx from previous reclaim Message-ID: <20200212074333.GM3466@techsingularity.net> References: <20200209074145.31389-1-richardw.yang@linux.intel.com> <20200211104223.GL3466@techsingularity.net> <20200212022554.GA7855@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20200212022554.GA7855@richard> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 12, 2020 at 10:25:55AM +0800, Wei Yang wrote: > On Tue, Feb 11, 2020 at 10:42:23AM +0000, Mel Gorman wrote: > >On Sun, Feb 09, 2020 at 03:41:45PM +0800, Wei Yang wrote: > >> Before commit e716f2eb24de ("mm, vmscan: prevent kswapd sleeping > >> prematurely due to mismatched classzone_idx"), classzone_idx could have > >> two possibilities on a new loop based on whether there is a wakeup > >> during reclaiming: > >> > >> * 0 if no wakeup > >> * the classzone_idx request by wakeup > >> > >> As described in the changelog, this commit is willing to change the > >> first case to (MAX_NR_ZONES - 1) to avoid some premature sleep. But it > >> does not achieve the goal. > >> > >> There are two versions of kswapd_classzone_idx() since this change: > >> > >> * commit e716f2eb24de ("mm, vmscan: prevent kswapd sleeping > >> prematurely due to mismatched classzone_idx") > >> * commit dffcac2cb88e ("mm/vmscan.c: prevent useless kswapd loops") > >> > >> Both of them would return the classzone_idx we passed as the 2nd > >> parameter when (pgdat->kswapd_classzone_idx == MAX_NR_ZONES). This > >> means if there is no wakeup during reclaiming, we would use > >> classzone_idx in previous round to sleep. > >> > > > >This is somewhat intended. > > > >> This patch fixes the logic by using (MAX_NR_ZONES - 1) for the first > >> case. > >> > > > >Ok, what is the user-visible impact that is fixed by this patch or is > >this based on code review only? Please describe the test case exactly > >and the before and after results. I ask because this area is a magnet for > >regressions and intuitive ideas often lead to counter-intuitive results. > > > > This is based on code review only. I know your concern. This is an area more > like art then engineering :-) > Then I'm afraid that until there is a corner case identified and a description of the impact it's Nacked-by: Mel Gorman > Would you mind sharing some idea why we intend to inherit the classzone_idx? > And for kswapd_order, we would restart at 0 if no wakeup during reclaim. > Broadly speaking it was driven by cases whereby kswapd either a) fell asleep prematurely and there were many stalls in direct reclaim before kswapd recovered, b) stalls in direct reclaim immediately after kswapd went to sleep or c) kswapd reclaimed for lower zones and went to sleep while parallel tasks were direct reclaiming in higher zones or higher orders. -- Mel Gorman SUSE Labs