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 6C20AECE564 for ; Tue, 10 Sep 2024 12:11:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA8C98D005D; Tue, 10 Sep 2024 08:11:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D59718D0056; Tue, 10 Sep 2024 08:11:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C20678D005D; Tue, 10 Sep 2024 08:11:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A45638D0056 for ; Tue, 10 Sep 2024 08:11:44 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4E9071A0175 for ; Tue, 10 Sep 2024 12:11:44 +0000 (UTC) X-FDA: 82548714528.29.4ED2B48 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf16.hostedemail.com (Postfix) with ESMTP id 9620A18000C for ; Tue, 10 Sep 2024 12:11:41 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725970200; 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; bh=cU8pR838pUgJYww5MTBtLvAJ7uBZWzriWAnrWlRGP0Y=; b=UczPNvxEAKYB+huS81QS5dbHyqGyxZDzQzSEHDRgxFo2x3AampEh8nXpBj9RBTMSOZGXPb KBbCo5TVgv7o2tkg45jZjxlDjI0aT5EbOju8Z2ju+xBtE+14u6eJvHFmDGhwGV4SiqcrSF Aswzc8mwSSU1dlucYELCF9T0gnfAt9M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725970200; a=rsa-sha256; cv=none; b=iBvF1CzcTN+arwMgLNh3AEEBMsYz5eFfejZs4KA3V5huaoWun5RsUYb60SXzqED4dd6pz1 WKuAiMiB3JtAAmzf8wr97ru2ppkbaqjZ4UeAU0N+THtp8LNjgVugdBby9CRPemtgSar+NC s4kjLrprLpe7eHDjTr18XQ29u4iPXLs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4X32bw6jxFz1S9fr; Tue, 10 Sep 2024 20:11:08 +0800 (CST) Received: from kwepemg100017.china.huawei.com (unknown [7.202.181.58]) by mail.maildlp.com (Postfix) with ESMTPS id 9FE841A0188; Tue, 10 Sep 2024 20:11:37 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) by kwepemg100017.china.huawei.com (7.202.181.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 10 Sep 2024 20:11:36 +0800 Message-ID: <26e53efe-7a54-499a-8d3f-345d29d90348@huawei.com> Date: Tue, 10 Sep 2024 20:11:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird CC: , , , , , , , , Subject: Re: [PATCH] mm, proc: collect percpu free pages into the free pages Content-Language: en-US To: 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> From: mawupeng In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemg100017.china.huawei.com (7.202.181.58) X-Rspamd-Queue-Id: 9620A18000C X-Stat-Signature: xf73g8mai3jukwb4bapzbn3sbmb3d54y X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1725970301-91491 X-HE-Meta: U2FsdGVkX199m3kOxLJ55TrVNg6N5iUUloyxRiYICWftK5ji/XhP01oaALNtOKLxrzJIm6ACeOI53GqyhMJnp3CduxsugYk+wKz+NczPgPxqks1lHQtu2pG1s4JU5GD0YiOQeNvQ5qpNOUuUeYa/aX26lE0bmQNjLXC2QMXjQdTIkp597RjH0dJ/euskggnAPPoBIDd0S+uo/nTNM1wktDwja1Hj31naVI1AV8EZsdpET1qZYAPDDCflBCmoJmPtZVSzBK6uUcwbJFR+ol1aF7it2v2tIFJceI4TQ/+vSp8wPdPdlbN+4bkXhHR7Jwbz1f7p0RB98I5mUHlkwv7LyV4I4O8+X/TCHSugb5c+yCPmzf7j7wDxlb/dHpPXo9cTTBZciNR91HBFTamvkEa4jlG66qNeqhGZTwxydH6qBfi7XYM3Dt6uy/slM17gUGnsvMadFbP50MRvzMyh4PKWqloqLbpHVRaclxuoLV7RaciHTKgynBayqMtS8JBmH+9yspmDBQ8V61bwEJ0llAXR0BNsaqyvxNo6TYXZfzxkc9fucBxyaAYQ6stKFXhyZqDNeX1CHmbiYg/K9y6Prn6Qv3jfHmMeXLU/kGx6hR6Jy/eg06s6EymlZ0d9hV5+GfWrFlxQzrQoFVIbdwx5yUGYMg4qXncbNg5oJOweop1eKyM/nHzAoF5bb6ueVb0tmTJROCM2woIA991rpUhRAte2xKsF2SrHLo+28GAvetmU0xM+OqQYJwBYk2BXjeD+vqXhtqjl66cdhui8DTxiw8pCy7jnS76ue0EFM5cmIb9dbaER/1hWGnwujoyIeUXr9orV1hCvNsd2+Qxg8kqcPLJBnr+WJ4k+PCKUDlpLfb9VemB/YNkJvkP1Q1yV61ZxHDzWUuF0KHrDMB5ZXo606SC3geUXwbFz1UIqRYxZ6RlIXuZ7C4G5g0JbzjTb89/qrBu9go7NmCrvtdiK5PksPeW UDkertXD rDUJBBk0hb1KTH07jTHsSVL5d1jrQQ2GXA2wSdXvj8tnDzczvhA0u++bT9ICgeK9vLVXmYaHJnRtaVvx6l7tDcpGyTnPtyfriCCNFbnovt8wOszWEG2qclS6RIcRbnOUKu3Cf8menI4Y7J+rfPVdsb9ssJWArebjp3loAdVtP3HHirt421Oz9S0Y/GlEAUnG62RIuzw2WtVls1uM897ujUGq1PQ== 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: 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 4b23a68f9536 >>>>> ("mm/page_alloc: protect PCP lists with a spinlock"). No IPI is needed >>>>> to drain the remote PCP. >>>> >>>> This looks really great, we can think a way to drop pcp before goto slowpath >>>> before swap. >>> >>> We currently drain after first unsuccessful direct reclaim run. Is that >>> insufficient? >> >> The reason i said the drain of pcp is insufficient or expensive is based >> on you comment[1] :-）. 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/ > > there are other reasons I have mentioned in that reply which play role > as well. > >>> Should we do a less aggressive draining sooner? Ideally >>> restricted to cpus on the same NUMA node maybe? Do you have any specific >>> workloads that would benefit from this? >> >> Current the problem is amount the pcp, which can increase to 4.6%(24644M) >> of the total 512G memory. > > Why is that a problem? 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 before 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?