From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E202C4167B for ; Wed, 14 Dec 2022 02:58:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42ED98E0003; Tue, 13 Dec 2022 21:58:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DEE98E0002; Tue, 13 Dec 2022 21:58:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F5FD8E0003; Tue, 13 Dec 2022 21:58:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 225E18E0002 for ; Tue, 13 Dec 2022 21:58:58 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E3B63AAE2C for ; Wed, 14 Dec 2022 02:58:57 +0000 (UTC) X-FDA: 80239404714.05.26DF104 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf12.hostedemail.com (Postfix) with ESMTP id 69E5D40017 for ; Wed, 14 Dec 2022 02:58:55 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kQreAXRa; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670986736; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T2Bo+BBjnqGGJw2O97UmAgNZFTgxTgab/gmI3Aw1OGk=; b=jcdJDILg/JD3TRIRAUfHH/9Ka7Oft60mPI0ewl/iWkIvu0ysyxYXw2LyC2tl07IJch8haG oexhOzIH2mk2pn81dfHRiVAB0k5Rrt+9HFBDTSa0J078VQ8p5zcjFmsOX92xDcfPMIuOaa /tfqWOsZ1fX9921KVhHsBIPmincrkas= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=kQreAXRa; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670986736; a=rsa-sha256; cv=none; b=47Qb2TVy+fdZzmh5uvFRvcLtY3EKgmharpm4dox+igOHOMjoSK4+ECdJ8SR0iLub//TRPZ 1Ugql1joUsukME3cSgGpwmLms+kiBJ2DlxmBZE7mzj8E9QlJlA9qW5htqC7QpUU6CE0+Ez MDvKkauOitVJ4m/COZn5K8RKU+ZeFGI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670986735; x=1702522735; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=ExjfdK4PVXcQs1nDQm/OvoUCmX5LNXAjOgYPOUopzVo=; b=kQreAXRae8sIJUcypDfyJ2QzNeson2NC2KyBsWhj89J0t42jSl/uo1LY w9SqJmm5YixFMkh4r9+VM70wNK7yMuGuSclDG8jzovIs2Oh4HCMR34toy DkNcru0QBozHF1/VxP+wiKtKcqFJiqfagPrOvNSgDkdj8yl3bRbj3qAjI Nlmyif6otOT94I52fjN68e8qtT3PhAREUaodnwt4r5Ft8+ZtVRIiwkwxa +uz8NFEWr2huUNiSyO3JIgk21pA91kHNXAm5fIhmDn5InpVb+/Fi96mQm bapB2Is24MYD/ROoFbIPpdvb/S7bjj14MgHCZf9ynynnuE67Hw+XS1N9h Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="315935595" X-IronPort-AV: E=Sophos;i="5.96,243,1665471600"; d="scan'208";a="315935595" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2022 18:58:50 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="791155668" X-IronPort-AV: E=Sophos;i="5.96,243,1665471600"; d="scan'208";a="791155668" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2022 18:58:48 -0800 From: "Huang, Ying" To: Michal Hocko Cc: Dave Hansen , Yang Shi , Wei Xu , Johannes Weiner , Andrew Morton , linux-mm@kvack.org, LKML , Feng Tang Subject: Re: memcg reclaim demotion wrt. isolation References: Date: Wed, 14 Dec 2022 10:57:52 +0800 In-Reply-To: (Michal Hocko's message of "Tue, 13 Dec 2022 16:41:10 +0100") Message-ID: <87o7s6g09b.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 69E5D40017 X-Stat-Signature: jrmxuoecz6a1azm95p7dag6ft6w53aps X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1670986735-445745 X-HE-Meta: U2FsdGVkX1/VjDk8bYj/iKs6cm9I23zUDR7CXMXpCOQXFOZUO1KRkxJTNaJPuL6u+1C1lx1kR0i33DxMqlruNa3ef+eRi22NQDaUJ0p8mJLSXkm1SFW+MvNLSZFm3mL2j0NujNny1SanekSDAxf1Ylk9tbv5nSJneZT4YswdaTmnU5JfX9lP2arzzVauAdsTiZzfLhKJ8aXwmOxBEOLMEKt7P8FPa9FJnwuN4pgM6sE5S6RntHEdsyy+vJB/1S4xR80yuTZ+Du/HIxL8KkXAySideyo9Joka5C6exLuUXVejaINICCIkh21ZLC51yDKfarS9GklFcSYA7Jw71a3lW0uu896/sQCceSJf3XeOhdIf1m05iLbVsa2caTzkdy/UjpCg1XX9zIbkGi6Yc/MzhKqEe6Ak9gdBUxxja0IRsTM5EdaWpQxncDMx8R965WYX63dw5FO+/eFzZKNB5+T1wNEdM511oHkiJ9hLFyVLyR/ksFey8qATarRha1xjVg6HaM8Ueusdgi+lkUkbBdwVKFpYAsaR4jWDN1sIVhvrKihRwVQLumFV5khM7fm+IkyJ9JOxWm4D7cJ91cIT3Sy4Q7rBX1I5ZepDu2gMh3qfKjjWQFyxwqlrpDZIEMrdeg0+GG0ufIbofP9RRQQI2jeqYKY0XbulXT+Wlr36XI2jCXPIIbtB93qQcHyjRIRs2eXz7WrkisXFAPdftuTc52ImH6q1UV7maJSZ/dEiFmq9/OzmF/8ViB5lhqBFJEnEFeMUFIvLsm3zqvIRQqvNOM+gnqTV0Hd2ShRpmZZwhesg7Lp3Aa85xoqPh6EQwM4vlv5EGkccWthbbrMYAN+gpqSkOMeNMa6pZcmLqVlDUTccopc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Michal Hocko writes: > Hi, > I have just noticed that that pages allocated for demotion targets > includes __GFP_KSWAPD_RECLAIM (through GFP_NOWAIT). This is the case > since the code has been introduced by 26aa2d199d6f ("mm/migrate: demote > pages during reclaim"). IIUC, the issue was introduced by commit 3f1509c57b1b ("Revert "mm/vmscan: never demote for memcg reclaim""). Before that, we will not demote for memcg reclaim. > I suspect the intention is to trigger the aging on the fallback node > and either drop or further demote oldest pages. > > This makes sense but I suspect that this wasn't intended also for > memcg triggered reclaim. This would mean that a memory pressure in one > hierarchy could trigger paging out pages of a different hierarchy if the > demotion target is close to full. It seems that it's unnecessary to wake up kswapd of demotion target node in most cases. Because we will try to reclaim on the demotion target nodes in the loop of do_try_to_free_pages(). It may be better to loop the zonelist in the reverse order. Because the demotion targets are usually located at the latter of the zonelist. Best Regards, Huang, Ying