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 6796EC433EF for ; Sat, 2 Apr 2022 08:13:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2C1E6B0071; Sat, 2 Apr 2022 04:13:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ADBFB6B0072; Sat, 2 Apr 2022 04:13:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A4D96B0073; Sat, 2 Apr 2022 04:13:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 8D5056B0071 for ; Sat, 2 Apr 2022 04:13:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4117118352D56 for ; Sat, 2 Apr 2022 08:13:24 +0000 (UTC) X-FDA: 79311224328.27.0460F55 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf10.hostedemail.com (Postfix) with ESMTP id 2B700C001C for ; Sat, 2 Apr 2022 08:13:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648887203; x=1680423203; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=tUJDWtBsVmdyxP5li7Z+DxSKC/ML2/OMaCS+cELECpE=; b=LyMpB2MOPMTUzbX4eDdRNbBhpTipC9zuPSCvwnUuUbcVi4vy/ESdop8n jSWMh8WMKiAgXx3GucpUuxLI7Uk3N7T9tfsJB3I8wuU6MMfnGkSpz+/eb LKE+VsAPWZJkbenFc58MO5eSbGrdYO/ABP9+I0a4yv4ObAvcZYIRc/Omc /Lui1Nd4goC2GI82SEiqkXs616PR97w/aw/1VndupaLfTiEXOHUzFV/o5 z0aBAq1LmaDuPBMNtfdK98rw6wBHNmoKWnBokwsjnHXpzlH2WtHLa1iGt bvkMzVT4S+lB554bXOHCj7SPyLKqNAc3KhlajfgZYWqKo/K3rnRZUayOu w==; X-IronPort-AV: E=McAfee;i="6200,9189,10304"; a="320986088" X-IronPort-AV: E=Sophos;i="5.90,229,1643702400"; d="scan'208";a="320986088" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2022 01:13:21 -0700 X-IronPort-AV: E=Sophos;i="5.90,229,1643702400"; d="scan'208";a="568127496" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2022 01:13:17 -0700 From: "Huang, Ying" To: Wei Xu Cc: Michal Hocko , Yosry Ahmed , Johannes Weiner , Shakeel Butt , Andrew Morton , David Rientjes , Tejun Heo , Zefan Li , Roman Gushchin , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux MM , Jonathan Corbet , Yu Zhao , Dave Hansen , Greg Thelen Subject: Re: [PATCH resend] memcg: introduce per-memcg reclaim interface References: <20220331084151.2600229-1-yosryahmed@google.com> Date: Sat, 02 Apr 2022 16:13:15 +0800 In-Reply-To: (Wei Xu's message of "Fri, 1 Apr 2022 09:56:08 -0700") Message-ID: <87y20nzyw4.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 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LyMpB2MO; spf=none (imf10.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2B700C001C X-Stat-Signature: m5bin7cpoujojkxb1bmhycs7xu71bgsp X-HE-Tag: 1648887202-651786 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: Wei Xu writes: > On Fri, Apr 1, 2022 at 6:54 AM Michal Hocko wrote: >> >> On Thu 31-03-22 08:41:51, Yosry Ahmed wrote: >> > From: Shakeel Butt >> > [snip] >> > Possible Extensions: >> > -------------------- >> > >> > - This interface can be extended with an additional parameter or flags >> > to allow specifying one or more types of memory to reclaim from (e.g. >> > file, anon, ..). >> > >> > - The interface can also be extended with a node mask to reclaim from >> > specific nodes. This has use cases for reclaim-based demotion in memory >> > tiering systens. >> > >> > - A similar per-node interface can also be added to support proactive >> > reclaim and reclaim-based demotion in systems without memcg. >> > >> > For now, let's keep things simple by adding the basic functionality. >> >> Yes, I am for the simplicity and this really looks like a bare minumum >> interface. But it is not really clear who do you want to add flags on >> top of it? >> >> I am not really sure we really need a node aware interface for memcg. >> The global reclaim interface will likely need a different node because >> we do not want to make this CONFIG_MEMCG constrained. > > A nodemask argument for memory.reclaim can be useful for memory > tiering between NUMA nodes with different performance. Similar to > proactive reclaim, it can allow a userspace daemon to drive > memcg-based proactive demotion via the reclaim-based demotion > mechanism in the kernel. I am not sure whether nodemask is a good way for demoting pages between different types of memory. For example, for a system with DRAM and PMEM, if specifying DRAM node in nodemask means demoting to PMEM, what is the meaning of specifying PMEM node? reclaiming to disk? In general, I have no objection to the idea in general. But we should have a clear and consistent interface. Per my understanding the default memcg interface is for memory, regardless of memory types. The memory reclaiming means reduce the memory usage, regardless of memory types. We need to either extending the semantics of memory reclaiming (to include memory demoting too), or add another interface for memory demoting. Best Regards, Huang, Ying [snip]