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 808B8C5B543 for ; Tue, 10 Jun 2025 09:18:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E065E6B007B; Tue, 10 Jun 2025 05:18:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB7816B0089; Tue, 10 Jun 2025 05:18:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCD396B008A; Tue, 10 Jun 2025 05:18:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A84F06B007B for ; Tue, 10 Jun 2025 05:18:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2DCBC141625 for ; Tue, 10 Jun 2025 09:18:21 +0000 (UTC) X-FDA: 83538940002.08.1E0F523 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf23.hostedemail.com (Postfix) with ESMTP id D88B4140008 for ; Tue, 10 Jun 2025 09:18:17 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 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=1749547098; 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=2o+z33Nxqbbwaz1qiohE/OVatCTc+vlkjerpM4rb2jY=; b=3/sbg0AeoObOKeT6hzu2UWxdEUbw8WlyiyAHwNKYil53D1Y1O8YJmJxq4HcoAvYgxSzTjH Anx37r5+iN1Gcz1ztKGlUc8q47gpgMLWzexgFDGmVa9YUOVasScIbK24ljEoD7HC41Mu/P ZyIvz+YzEQkhPSXIIYsHRG7qXAT913E= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf23.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749547098; a=rsa-sha256; cv=none; b=AlvEXc5tBcleKQE59fQrwRYdtxKwzpH5nQiC73IJxMC3vY0HZVw/GF3cmHC29pSnq7WVQv CBwZhgwJC39zDQB2VP9JnRjoSmi6Q+kEbf0tWFqT8iTV62CQlaX40XmAvSFhlVGkVKELtB aSH09C+R2bey/3RFWVOpFLY8z0PIDyk= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4bGjlW1z1DzRk7K; Tue, 10 Jun 2025 17:13:59 +0800 (CST) Received: from kwepemg100017.china.huawei.com (unknown [7.202.181.58]) by mail.maildlp.com (Postfix) with ESMTPS id 08D72180087; Tue, 10 Jun 2025 17:18:12 +0800 (CST) Received: from [10.174.178.114] (10.174.178.114) 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 Jun 2025 17:18:11 +0800 Message-ID: <7691fac7-f569-4fc2-9d0e-f7dad4139261@huawei.com> Date: Tue, 10 Jun 2025 17:18:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: mawupeng Subject: Re: [RFC PATCH] mm: Drain PCP during direct reclaim To: CC: , , , , , , , , References: <20250606065930.3535912-1-mawupeng1@huawei.com> <20250606111953.GB1118@cmpxchg.org> In-Reply-To: <20250606111953.GB1118@cmpxchg.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.114] X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemg100017.china.huawei.com (7.202.181.58) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D88B4140008 X-Stat-Signature: ig6u8juct15fw4nk6qoduj4mbzqsbuq3 X-Rspam-User: X-HE-Tag: 1749547097-131104 X-HE-Meta: U2FsdGVkX1+w9ergPEmnjRo+kYEj3fYhNx9s3G/y3ToFFqvr0oYscuFlWxJ5yqdkI1Omb5s1CrMt3bEmPhNQgVy+LCvYmggV1Gyn74AgwfztVF4vSnW1edXSefIu9TDPIllCd4DjgFXH8bNuRRFPtHDrDC2ieERez8wcr5sO+2Yop0usVFg5HWFrd6ZSmYJMbCncVOy+sYjbk70jolhSaqHs6RlKVy48RH4VX4goUdAGs0TBSliSbhA7GlgCiJu37+ZeMoGz8393rAzOKbCJEDPBxErRO999CYqurqTEoF/wHhh8DS5BEmxBTcQOnBU3xsR2MKIpA3a1yeFcGrbI/zTjUqbXBeDLhA7qiPzwTn0XOowAblX+MgGlYbLnnJP5O66STTc2cvD6Drd/bz3IgxHnkY3YZU+kqypeZ6Ob6kjiX9F41Qx/qPVNumiL+OfHl5V3v44s34EE9JfaqyBtfqvM6ofvzkIc7uMjFZpO509XIq8nb0EKJzMstCoRDfXgQlPYbxUbhMLwCjEbN5J1qFdwmTqIP1QUAQguwn7IIf+ls0QUfaiXVXiOoycEsj9MwJ7PtPFi6DQ4mu1qwtJ4luTDmBMDRpgFiD0WTZmsbsP6YK/xqi/NRO4B0kXUP09ezRovlBKFMWoHOsfDFgqndB1W5eGch93RYkCM2FYG50QnK53k82hovvgAaDbuHKazZJDOTPvvt0vnuhduZqn0wqwkYDYg35orn4KW3RWoa6qk4os/SWkJ8yH7ldumUH2K/cYS94LuZxk7zOwLt76at8R6FsgMj5TNmBGX9JJM8ve+tOt8lXrApuXS3mDBtxjsQ4VS4ZxVMp0UueK55t8uo8IAG360pGu+LnyD08I3aShtpcYiyqzkLPsGBmVpd4OaT4ySX6pcjKVh+QibJ9iPapFDeoWGZDVKZbIv4dx5FX8Tk6EwcOKKrZZHQEOUKSkrwh8avvM8ITtp4Vn39RV gV8ej4I9 yMm6zE7UiQJq7ZHML6f/2zbPy2b2U9RDUeq2CV4DufqPOSgP1wfttyQ8jMaoxr5pZ0MOOOza0kYHHEyLE+VBBRiJ40Qy7hlHOq4nCeAxNMxEldvhEEadOUjOp4KdBghdaoWFPN9iMq4RfuW9kMxFQTj++etk8+TMK7DF/gLJGgbzHX8s20cS1oiioO3mnH8APk6SWCYZv0+yZrMtEdJoF3xlrKA== 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 2025/6/6 19:19, Johannes Weiner wrote: > On Fri, Jun 06, 2025 at 02:59:30PM +0800, Wupeng Ma wrote: >> Memory retained in Per-CPU Pages (PCP) caches can prevent hugepage >> allocations from succeeding despite sufficient free system memory. This >> occurs because: >> 1. Hugepage allocations don't actively trigger PCP draining >> 2. Direct reclaim path fails to trigger drain_all_pages() when: >> a) All zone pages are free/hugetlb (!did_some_progress) >> b) Compaction skips due to costly order watermarks (COMPACT_SKIPPED) > > This doesn't sound quite right. Direct reclaim skips when compaction > is suitable. Compaction says COMPACT_SKIPPED when it *isn't* suitable. > > So if direct reclaim didn't drain, presumably compaction ran but > returned COMPLETE or PARTIAL_SKIPPED because the freelist checks in > __compact_finished() never succeed due to the pcp? Yes, compaction do run, however since all pages in this movable node are free or in pcp. there is no way for compaction to reclaim a page. > >> @@ -4137,28 +4137,22 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order, >> { >> struct page *page = NULL; >> unsigned long pflags; >> - bool drained = false; >> >> psi_memstall_enter(&pflags); >> *did_some_progress = __perform_reclaim(gfp_mask, order, ac); >> - if (unlikely(!(*did_some_progress))) >> - goto out; >> - >> -retry: >> - page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); >> + if (likely(*did_some_progress)) >> + page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); >> >> /* >> * If an allocation failed after direct reclaim, it could be because >> * pages are pinned on the per-cpu lists or in high alloc reserves. >> * Shrink them and try again >> */ >> - if (!page && !drained) { >> + if (!page) { >> unreserve_highatomic_pageblock(ac, false); >> drain_all_pages(NULL); >> - drained = true; >> - goto retry; >> + page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac); > > This seems like the wrong place to fix the issue. > > Kcompactd has a drain_all_pages() call. Move that to compact_zone(), > so that it also applies to the try_to_compact_pages() path? Since there is no pages isolated during isolate_migratepages(), it is strange to drain_pcp here?