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 B6705CD3431 for ; Wed, 4 Sep 2024 07:28:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1400C8D0232; Wed, 4 Sep 2024 03:28:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F05E8D0228; Wed, 4 Sep 2024 03:28:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED2558D0232; Wed, 4 Sep 2024 03:28:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CEB4B8D0228 for ; Wed, 4 Sep 2024 03:28:33 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 83778408E6 for ; Wed, 4 Sep 2024 07:28:33 +0000 (UTC) X-FDA: 82526228106.02.0C8497D Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf27.hostedemail.com (Postfix) with ESMTP id 7A31A40007 for ; Wed, 4 Sep 2024 07:28:31 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EZB2k8b7; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725434784; 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=J6qdMBsqF4Z+FiZII39Epw8MqLI1PNaBWTLLXYuV8FY=; b=jjSjQo9MGqoXo0p1TsrAs2iwU/7nwkj3dQMsxKckZv67U31VtadWuVU6/9EXSYmsWNoJvZ KBDky0BTkh3bNzoIaAh6/vJTmaf2eEUZunDLtQT8Ig3st8c4ci0/IHcM0gOfQd/gpZIZLB c0US25enNtMX9meDOZ4a1eBDQIrG2gI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=EZB2k8b7; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725434784; a=rsa-sha256; cv=none; b=X52MM/rn1gi1p+f9Gw8FKPN8z0qyAKo1nzlW1OMLkaiXuYqluU3Hh/8pfJzGa/apfA8j7L s7DMNt/9X1CR0LcWe+SSjUlFyjuEI3o4vPl7K/V7ce7TpIaK6GfP+IXSpzBJPuHnTiIjxz 8OhrJeV6ADmBaiuj0XBA2X2opm4Scnw= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a7a843bef98so651283266b.2 for ; Wed, 04 Sep 2024 00:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725434910; x=1726039710; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=J6qdMBsqF4Z+FiZII39Epw8MqLI1PNaBWTLLXYuV8FY=; b=EZB2k8b7k3hQw+BCRZ6SwP4ESZUbnOKEMpYhwquvj6xeZBg3A6YBW6klyUY5q/tzX/ SVgAZubWJHexEP7aFyXY4wFtfYKXjUKuUXh5arJfjLLowyrr5U4aaVHbMm1SA/WHhcUq J5DEOHEL9YDEP/m+sfrGY93BO/jfV5ezIkZ2ssd0BUzWDC3ZYJzBjczNS2hzaZq/48EW YdUujAYwzfUT1LMr6HZxXsyxm7AZK6Y4DD1GmdglXxs0XZyIIcsrAp23RdZ7LdPTcOHy xqMlMYHbRb8DZpNt1fLveQfmXCNfTHtsiSIbpzmciEjU2gbOPNKlJlu/A8ZwJ0n1JOR0 EPEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725434910; x=1726039710; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J6qdMBsqF4Z+FiZII39Epw8MqLI1PNaBWTLLXYuV8FY=; b=vkLGHQsomdZl9aOCknVisIgPcBm0g+ZX9TKFE2i2h2YTlzqlRAfisZSIi4xsJmDxNI Gqq4WmqKt7rZZheokW21ch+Xz1KWaT3c/jNNTQjsp3yZykqFMyAZyatfue/yWGDB2rHC GglzyAqbWgvQibX01mbmPb60w/D8EukvHIvGWrWW04BeMNy2011lWcNwRL/xtX6bLFOS ELr8JNABFQs8xPF/LAI0+9nYxmvMdEUFypaWqFE/QlkkFXZ31QAZs49+wjD4WFTzFW1h lyM73881uc2vhTyAPwzZa1Pj2kZQkw8UFEvFM7RWnA5j6eXo7o91qxghI28nuhfIJXpT Zu6g== X-Forwarded-Encrypted: i=1; AJvYcCVtJsnkhhJMTzywfXzNU6N3MZ4TtislQ5CO5TflU7aocp10BPolu7bD4PjJwpXx1YdQfe3UWUp4Pg==@kvack.org X-Gm-Message-State: AOJu0YwrlaB6xHp2wKYVacuDBHjBlf/c8b7BvKwPLy9zvSKXVY7buvqM QCnPbkmmyi21+9y1X5c3J1kI0MXw6giM49/Fv5eZUAG50QowO8xC+zn++14NYzQ= X-Google-Smtp-Source: AGHT+IHqeINE8uL24sTo67uUEfLYKO9mI3n/C4gNUn9/4dRLwQmTRkmQWzcLQ1+t8l//y7Hv3+m0tw== X-Received: by 2002:a17:907:970f:b0:a86:7199:af37 with SMTP id a640c23a62f3a-a89d8ab4ac9mr838783566b.58.1725434909818; Wed, 04 Sep 2024 00:28:29 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8a21d209d6sm196962766b.180.2024.09.04.00.28.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 00:28:29 -0700 (PDT) Date: Wed, 4 Sep 2024 09:28:28 +0200 From: Michal Hocko To: mawupeng Cc: ying.huang@intel.com, akpm@linux-foundation.org, mgorman@techsingularity.net, dmaluka@chromium.org, liushixin2@huawei.com, wangkefeng.wang@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm, proc: collect percpu free pages into the free pages Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7A31A40007 X-Stat-Signature: xp1qoy6h85bz19e891qj76gqpayrqcta X-Rspam-User: X-HE-Tag: 1725434911-867903 X-HE-Meta: U2FsdGVkX1+VfMOTITO0AGWuIDcy2dV9s089kb2oZh4AwcHVcouD82S1Nu4bP3f0Mk5Im4t5wsBn3aDwglJHcnqE7NZJJC5gAyQC/0CGyXW/7CsI3UkS01zq4R2Ynqe/fYMXZqsEY6FiIZ1hlG1wZ7OkJ58HJzytvKD9FfiHqeMJ0IOeaQeEeNJWE1nsk55FJpKBzuBg1ogXlV62vCvUuWKuo4c9L4eDdzm2gk+bm1cAfwgq+0jxXL+X/SSl/qsl45I0P7eYhS4oQOPJxe1ZhsTazdPduwzB/um91uNh4BdNE6hmpXNhrCMDZCvMYXZsxddbItUuuznzwci2dEQbsaW9Q85KL7X6sba0GXhcHgf/VG/JcgmmrVgBtPeMXO7e34ZfNdzUmGK3TCLcvdCp39yPyBTbccPraOFQUOTr+zd9n7TQtjMpM0bqyepDkaCXZobjUUgK0aPZ12vPr4EdDeHFVKjVil5eO0KxjYadYRcesijxJMAArkrfrTwDEqb7JshiX1uQfR4KGVRv3wd99vjd9R11nzZesGhwp+ht074Cz65aAsrHXAzVx1dex5/Nyj2qlAHq46YvYhAZ8siS5FzAD/6fwFdUE17rkkL5gZXmulvtZzpa8pHVVjn69P0M0jv6V03y5r9Z8PnPozxJpXnGi08A0EAa3+CnSqNBZ1O2YZOQly+O3wuHP5gen/YODx0DxMdgcsaS4h5vYCVC2bLoohmw7EbJZ66XMK6qze7fyPDKXtmEsyVV1YIl0jqRsMRjQca3MnSENrhOKa+cDvtMYae/xDkFYSBj/44WspaGkU8msuGK5h2oiVnjFXvosA4wDspGsGU7wYYKpcC96s7SrHrYaxUk/AXnwm0+ragnul2ZYfCNpRAMbWMgAhqCUVaDeXKYsrJCx71CHQZ64y456/SEC281wPmFS/iHfGt3xJZloxDBiWVVoGXH8b5nXJZz8KnrNLSXvnM1ewK VeM3W08q gEFpsAyBiRAeF6+sHHNwBNyOM7g5tewB9dJ3l4Lyxz6ZR7rZrCV8ESEekFV3dq41RR6k8PHDE4nOeWgUMEM8RcS3+iEoWp0bw2BGFsnGcXI6cwRZm8kLP/QIwcZBxK1RaMgawzlbU8ODkNsuGQ180A2WMNCbvQWF+90odUKmKm1i4D/lQ4bVj15+6U0HxK/sRa/AT2SUJkQO43wJQCcydHscRAHySpq73+JHGCfcMyeAGsWG7VHbpzjLE8R3kMdlJagiqKjj5JSVeVEuc1XWpNQ8k0dp3fS7dAbFQzosq3e/GHQb6mqHv5JvUeMsDH6BF9/AiD/+fOSWXWILjkJ7ww32A7W69z0yAjPkpLmeibL30hER/JYAqVpv19g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 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? 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? -- Michal Hocko SUSE Labs