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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5FFAC4332F for ; Wed, 14 Dec 2022 02:58:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237151AbiLNC65 (ORCPT ); Tue, 13 Dec 2022 21:58:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235717AbiLNC6y (ORCPT ); Tue, 13 Dec 2022 21:58:54 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 977D313F7F for ; Tue, 13 Dec 2022 18:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670986733; x=1702522733; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=ExjfdK4PVXcQs1nDQm/OvoUCmX5LNXAjOgYPOUopzVo=; b=AM7H6Ht1urGG4xkKzHQ6s3MtKyzG5i1AMSL+cKHnLMberSlvxQk7xWgl arK62jFTIrvzSjtlrPUu5N/R/gfHt370Q7zN/O7XzqL37Ba2fg5J3FDin getatZph1T+2G99qVsgwBM9PsziwpUB9+OKkh9ypdj6IH2RHbrpq3IqT6 PVuFqbOBOGmbUh71A/oLz9XZysUhN/C+eznbsN1Aqpm+K3oR0OTLJtNrR 6wSdEqptpKWN7lzTuqHY5oes0cibJIBJQtOfGEKcEx8yQRMueOia5AVJN tk498DpXGr1WKHmoN1Zd/XpJTocf24d8EZp/2GmX53Nu/CFmgnmhdAVS+ Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="315935589" X-IronPort-AV: E=Sophos;i="5.96,243,1665471600"; d="scan'208";a="315935589" 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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