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 D8A1DEE0209 for ; Wed, 11 Sep 2024 05:41:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C11A8D00FA; Wed, 11 Sep 2024 01:41:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3731A8D0056; Wed, 11 Sep 2024 01:41:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23A558D00FA; Wed, 11 Sep 2024 01:41:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 04F588D0056 for ; Wed, 11 Sep 2024 01:41:00 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9D5031C5326 for ; Wed, 11 Sep 2024 05:41:00 +0000 (UTC) X-FDA: 82551358680.10.1756908 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) by imf25.hostedemail.com (Postfix) with ESMTP id 2C7C2A000C for ; Wed, 11 Sep 2024 05:40:57 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=XR3b97gl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726033254; a=rsa-sha256; cv=none; b=zxl5qdfPV3ZPBdD9LnuGwQMqFVYhR8GYKKv5vov6WxdW1kxsXpFvV2kB5Q46nEIH4CSMdR 4IZoWwrtj6BxWKG+k9ptKz4Z2RuFW6LAjPU44jtA2WTgxqKRL3Z+cOcCDl1jik1Y7DRZBz jwcb2fLYgTW9AXRsfng4BiJvVm1S8YE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=XR3b97gl; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.21 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726033254; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zZggKoRIzKsXvKHWNoCedtao2iot2qUkoUoDnmlbmSI=; b=4H+mrbCJid5BVE/L2m25aL78UlFQY8b1bIEZCIbwSc8oD+TEqcPq1Mb9C6VGuCVBSrAazu rfInyQy4pnmER0HoqQnkjinMjXcibMzSKxLoB4QsbmVi3DZU9HsAx86emDlVkolVObQ52t p64iJy+JTxQAh20HeCNglyS96RSYDPs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1726033258; x=1757569258; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=KfAJtckaD6t8IGSFSxVgsxEymkRmCe4w3REfGus+RGA=; b=XR3b97gl0cMi2Hn+2a5aR5pktnFRsUq7f8bGX1i9HxqPF/yKXCXP8CT0 4GJtLutZEkQ1ofU/2bR8ojdeAGwmfbM2wF+eXA47Oamzq5JJcRYY+6tbR N3BaEMpZYz3AkMH9MBlbfGsufV/E62o+3w5p/Y8GIBX7X6OPpDurzQe3o EGotSW+ZTcnsx8Jm7scmbRvGYI2unrSTmpOZYNQm+VuLE68sYZGe82O5R 6qtzZ9pUdaMg1HSyMeWWCr0ycYjmpDo+ZY9r09/hrlD0d344xCYawvHIk wO/PlV+RckasKaMuNrPjRWEcHIrRlj/YvUWB/IW7wjbvcUPvt8nIyXsvo A==; X-CSE-ConnectionGUID: iICDxn7rSYuhC+svQ35ymA== X-CSE-MsgGUID: +j093dz6Sbqkbhzr4qDvug== X-IronPort-AV: E=McAfee;i="6700,10204,11191"; a="24750943" X-IronPort-AV: E=Sophos;i="6.10,219,1719903600"; d="scan'208";a="24750943" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2024 22:40:56 -0700 X-CSE-ConnectionGUID: 5DAuK9D/Qjm+/pmx3hkAxg== X-CSE-MsgGUID: j/hCGuhTQS2C2v54ohRnaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,219,1719903600"; d="scan'208";a="97953780" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2024 22:40:54 -0700 From: "Huang, Ying" To: mawupeng Cc: , , , , , , , Subject: Re: [PATCH] mm, proc: collect percpu free pages into the free pages In-Reply-To: <26e53efe-7a54-499a-8d3f-345d29d90348@huawei.com> (mawupeng's message of "Tue, 10 Sep 2024 20:11:36 +0800") References: <20240830014453.3070909-1-mawupeng1@huawei.com> <87a5guh2fb.fsf@yhuang6-desk2.ccr.corp.intel.com> <2ee7cb17-9003-482c-9741-f1f51f61ab4b@huawei.com> <871q22hmga.fsf@yhuang6-desk2.ccr.corp.intel.com> <193da117-30b8-425a-b095-6fd8aca1c987@huawei.com> <26e53efe-7a54-499a-8d3f-345d29d90348@huawei.com> Date: Wed, 11 Sep 2024 13:37:21 +0800 Message-ID: <87h6amwy26.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: znc9embwgjox9okduy8uc7hx4ja5ryw5 X-Rspamd-Queue-Id: 2C7C2A000C X-Rspamd-Server: rspam02 X-HE-Tag: 1726033257-989896 X-HE-Meta: U2FsdGVkX18U654WWfZ8AQEj1f//qyto+AKIl65HlEvNjWRFjGoilXVg18N1cmdqMwuBJ7oQOUdxoShbkhqwkWB3IID2RzdBmim0V70i5Yw0nMKp5UdrX2RzhYqcdrP3OwowMVUuacYcspRhWbQDwHc5hDMTgRDH53J+JoWu1yYOrhBlLaq1FBY7w2X8GviuOcGvVlSt91r3hiZWhrtyz0F5RQjB5b9/Ad4T0TvBpFts3EaStGWGmaAr1HIdSSxjjBCaMbSXFp34DjQpfXJ+TxFUXogQCxZ/FRO9L7O/XXLfbYAvEGRyU/rUie42alhgBQjMJP3u5OmDRwo1z5OuLBW8UXCrezjJtZSDIz8cGgyYr6EoPZWkW9WgF8GyKbAQ82gIfJv3buKr6R/FQ/5Dzas0lutNcvolvxfaG5X6nRIm80xiv8cX3HxGWX+Rus6WmfgkQvb2mCa7W33BXqIFxk7DpMAalHM40+lmunxvA+xHyxAMQbpUiVx7+vN0UcExZv7yGJeRbHk608UGV8MA/Po10ks17AW4f2JhlkgQvXEo0NRUaGvDZgT0utT4l8llfyDS5GVLw6VtIUluCuLZQa8xGIlPhdobMEhALufVssUC9d4KWIJIScimSXd/hA/uW21bZMoaHF44IdLE/+yp67kiu1K1gLrWMMdsKDtlVyTSNPnMv9Phk/zgFkkJJMQD1K/7XOr3UrrR4fJXSeO+xpRNVSTbb210T6oHUw1kKsIqWahsPioMzvCE3H8IU8r4kUn9oJUdFOYU4CrtMjD1qpqknxYLq1QSuIuA1mM25RhAVE6aCGxpIboXseI/8eIeYLKaoD4q0STpuOg7pCOTy4H25auBNUq2MHx29hOfC87geIYHFPFRnWwLZmaQEUPVLrf4pazpgGXhwQDSTDuyjMiKhPGbQirnM8fDtqx1j4y2SkADjnEnHeqR7K40XYsrwQWaSOQ7BCB6Mw8LFz/ 6Q0C0fLN Z4hpvo/MHlebells28yF1SLt7gOhKl5zVpdBB0XridSAfy03EXWkuIH+BFgSAGUVs5Qlqy8bHgCNLl0uejDE6eiSrIx5Z1YgjDikSODESPYcicMIQZpTue/YZMlS6oTmyZwRJxh1UTh0mp0swDampMCnYqbMdsdn4xFf2A5N+fhjjCkMsLr7t3Uk2SVUkOR6g4iinSyY7K8Sojci85p8bFbupwg== 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: List-Subscribe: List-Unsubscribe: mawupeng writes: > On 2024/9/4 15:28, Michal Hocko wrote: >> On Wed 04-09-24 14:49:20, mawupeng wrote: >>> >>> >>> On 2024/9/3 16:09, Michal Hocko wrote: >>>> On Tue 03-09-24 09:50:48, mawupeng wrote: >>>>>> Drain remote PCP may be not that expensive now after commit 4b23a68f= 9536 >>>>>> ("mm/page_alloc: protect PCP lists with a spinlock"). No IPI is nee= ded >>>>>> to drain the remote PCP. >>>>> >>>>> This looks really great, we can think a way to drop pcp before goto s= lowpath >>>>> before swap. >>>> >>>> We currently drain after first unsuccessful direct reclaim run. Is that >>>> insufficient?=20 >>> >>> The reason i said the drain of pcp is insufficient or expensive is based >>> on you comment[1] :-=EF=BC=89. Since IPIs is not requiered since commit= 4b23a68f9536 >>> ("mm/page_alloc: protect PCP lists with a spinlock"). This could be much >>> better. >>> >>> [1]: https://lore.kernel.org/linux-mm/ZWRYZmulV0B-Jv3k@tiehlicka/ >>=20 >> there are other reasons I have mentioned in that reply which play role >> as well. >>=20 >>>> Should we do a less aggressive draining sooner? Ideally >>>> restricted to cpus on the same NUMA node maybe? Do you have any specif= ic >>>> workloads that would benefit from this? >>> >>> Current the problem is amount the pcp, which can increase to 4.6%(24644= M) >>> of the total 512G memory. >>=20 >> Why is that a problem?=20 > > MemAvailable > An estimate of how much memory is available for starting new > applications, without swapping. Calculated from MemFree, > SReclaimable, the size of the file LRU lists, and the low > watermarks in each zone. > > The PCP memory is essentially available memory and will be reclaimed befo= re OOM. > In essence, it is not fundamentally different from reclaiming file pages,= as both > are reclaimed within __alloc_pages_direct_reclaim. Therefore, why shouldn= 't it be > included in MemAvailable to avoid confusion. > > __alloc_pages_direct_reclaim > __perform_reclaim > if (!page && !drained) > drain_all_pages(NULL); > > >> Just because some tools are miscalculating memory >> pressure because they are based on MemAvailable? Or does this lead to >> performance regressions on the kernel side? In other words would the >> same workload behaved better if the amount of pcp-cache was reduced >> without any userspace intervention? Back to the original PCP cache issue. I want to make sure that whether PCP auto-tuning works properly on your system. If so, the total PCP pages should be less than the sum of the low watermark of zones. Can you verify that first? -- Best Regards, Huang, Ying