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 5FDA8C369AE for ; Sat, 12 Apr 2025 13:09:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2020680040; Sat, 12 Apr 2025 09:09:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD06A68003F; Sat, 12 Apr 2025 09:09:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6EF4680040; Sat, 12 Apr 2025 09:09:16 -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 9995C68003F for ; Sat, 12 Apr 2025 09:09:16 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6D3AA1A1344 for ; Sat, 12 Apr 2025 13:09:17 +0000 (UTC) X-FDA: 83325422754.02.84849D8 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf01.hostedemail.com (Postfix) with ESMTP id E0D1840011 for ; Sat, 12 Apr 2025 13:09:15 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QZ0+5zr2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744463355; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references:dkim-signature; bh=LeE90RsIqmek8a5r9ooo/JwJr81IVEM/R4FGmrxaySU=; b=uI1OSU17mG/yPUip4w242UMyFnwvF8QU9mMD2sYGWwoLP2sm9LYWvHAu4nJHYM5CLUtIto anYDcJskE3JBTAWudR88TglIRzNjxFgkp/x44bJELIcLAdGFu6omDx8VcXArBAW0SS3dMD 8syN/CZOKaiOVzni1QaMYS3xAivK65s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744463355; a=rsa-sha256; cv=none; b=n/RltDnbNbJguheZ5h4zYucjL2R4oVlTCNjESi+4a3q3TPfV2kj0QV2kc6txqxA5dKM/kP d7q5eeasNbvpwoF5FqrnAgCVFmja1wmd6y7+fAFjVC5E1GzMWCNhBzPNk0UWSZ1BmAEJiL lZOdmjqVRqoJBZAxw8dDDEm8Dq8/+oA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QZ0+5zr2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-736b350a22cso2473694b3a.1 for ; Sat, 12 Apr 2025 06:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744463355; x=1745068155; darn=kvack.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=LeE90RsIqmek8a5r9ooo/JwJr81IVEM/R4FGmrxaySU=; b=QZ0+5zr26rOg4Hpfcv8Por0VkTyNh6uYS/yP3JRH/3BlUIBn4tmQ4Xlya/W05XjtwT wVhXdZ/Uo9+NoSCo5rO6hEh8H83NRU8F7eQKraCRIbrzKA2YPJ6qFFa8NgROnAjAEDYW qdmWM/MVpEBTYf+/6OGCkD859j/muFpBnl+onbIy/Zvh54VMPF7VfmmmU4JmMAPYtBHG r54QiN3xFkeQ281KfyQDr+QBZpeI+3Gviro489JWNoRSNK21HjLHffpxcKfp1DF1c3tU 2F499KmBk1RilREMVDCDN+PJy+3DizYlspnHmgFmFrf7jefsh152Dja5Be0+US8I/bU7 5rCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744463355; x=1745068155; h=references:message-id:date:in-reply-to:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LeE90RsIqmek8a5r9ooo/JwJr81IVEM/R4FGmrxaySU=; b=Pigox/jS8LY/RdqsFeL7GMmuy1Tc829UV59FhotBgpITz9YMzpuYFCj7MbubRkge+1 p962gxMprVKr3r4pAWyQorXGQ+NFakSJOpnqEUGVUtRM6u2WdjcmY8Gg5eHzjmdgfwPi yqvjCjkbPIGIcLouW4uXyKb43oGbR9krisIg5JpwTm5lKC1ub51IquGfE6dtqxFwfZed 2CgftrWXq3NlSzXDSlR8G9ySvlpw1/HEjTqjXGLf0nq1q1DRRa+SiKXkplDC/zdpxAW5 dUg2rFuhZKPOs3IFtKu+iYIcYyJOH/+i/YfR8QD/iZYtlQXOdo8uCG2vRpUlUMMJ7AD1 Vp5g== X-Gm-Message-State: AOJu0YxQI0LHXYt+83E2uNgTEybSxh2de0ST+BifFcyJQwyo3CXLXJo1 hzmZaqzf3VFB/yqJ635CA7aZ2R3Se5A2SOrEVTBynJdI2yCeH9QF X-Gm-Gg: ASbGncuO8PIk7eVJlPcGpQ3zFASTtlvStiSV5BN/hRpjXu7ZFjL63++UiXHUmvBvku3 k/fVddtqJcz7x3UGC6RuTN2tEF5SXtn5RLs14s1VDnaP3e+6WU+9mSAcbMWJpsiaqdymabbkdZp /N16PUKOMP/4qYZ/kPowLeYMjS6VksRuafrkgCMx6B+l4WCM3qzbeQDt9cqCsgmyp/ZnsIOZ0HR 4wFZYNiR7FAsV4ZrPAS3EWFJBpKEuVzCWvOK846hpdsPKa3jiRHIAOb2l8dGT4QPAJ1oqdL5fTV BUI9UfiKkBLdp6M3qZish7moMN6KeVdBEw== X-Google-Smtp-Source: AGHT+IHBsDfcdsOcd7CplkH7Dbko5DJ3EkuJ4/wwFpSfM2dGkBYge17HnJ1c3n3cLTh4KEO6EZWJ8Q== X-Received: by 2002:a05:6a00:240d:b0:736:ab1d:83c4 with SMTP id d2e1a72fcca58-73bd0ea5de9mr7961287b3a.0.1744463354484; Sat, 12 Apr 2025 06:09:14 -0700 (PDT) Received: from dw-tp ([49.205.218.89]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73bd21c670esm3446935b3a.69.2025.04.12.06.09.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Apr 2025 06:09:13 -0700 (PDT) From: Ritesh Harjani (IBM) To: Gregory Price , Matthew Wilcox Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, donettom@linux.ibm.com, Huang Ying , Keith Busch , Feng Tang , Neha Gholkar Subject: Re: [RFC PATCH v4 0/6] Promotion of Unmapped Page Cache Folios. In-Reply-To: Date: Sat, 12 Apr 2025 17:22:24 +0530 Message-ID: <87jz7p1ts7.fsf@gmail.com> References: <20250411221111.493193-1-gourry@gourry.net> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E0D1840011 X-Stat-Signature: 83x5p681ts78q8pjpym34fyppaoxk4t3 X-Rspam-User: X-HE-Tag: 1744463355-296143 X-HE-Meta: U2FsdGVkX1+FILG2GfqlK0W2GElBhPi65hJQ87/zeht8Xio4uPRTYE8Sim9XS4wuw4khTYSFzBdsqH/HACxK/rb6jl+huVvPCzl/xrzgHjzu/elKKe0mErtCroFzyOhf/jzDEs7tgxsH2bXjUNvQL3XhddiCjUbWUveLsT9sYrFPOZ6Ih8WmW1BNeSb7ypTjOQi61VPUZpShBMX84l32t7v/KyFdtwcYqcorKBJEiGgh6vsN+b7cuLPRaZ84chMaTuZHfH9grBmMDWmD3e3cqhq/avOTWuWwFAUNZm0xBOXkJucrcVihDC2DnVcb2niMHcZUHWsnYoyP9RzReBUBI/il/D226/D5Ouzrr7515JLkWvW7nvncGBE/iL+o14MAuEhOokUkFw9+PKTAciSNeTAyb9FhpRKR5SOVOlaJ256hMgxoDxpzw0o7MWHgXBkECEWcU91WyanGwlstm9uN/kpVc//ncKLitSq9nfskw+LxBJRvdnCr8h+7OdcrezIHf49W67zhkkeygPdnogl8J7oNV2DXZ55UtRK3n7rE9B2q/E3KNroKL2shSHs4fHr0B2p9M8MMGT/v/iBaLYjAM0tB+NMt7YH2PB5HvKR+WQbkkz1s4dWeGAGiv7NIPhreS9cdbd1zCYdjT+TDVWJePVxS2L4UF0ZcLtg9efX3VjufSRf+p6M1Mrt02bREClXUyK2/3GY2/6bhRmm8egyulTe5NPrxy2/I0Kw1oYD1SMdorI1Av0sAHL62bHsH4dKbxBuEVWNl20wBt7x6b8Ued7Tbl9yb7X863FVNvOUHJNNhQMYPT9U862WNhxmIY0A4wtaWsvUa2Th3bPND0YFQu4B2ANKpmPdKsq0bgO6/zgwYzWzC8FGf5Uk0jGA/Gn3XItF5MCA6pOf8D/AO06lHdLx+8yeA/X5l3wcGTKG3TPYMdegMVtw6qb4CDCr5gV2Nr0BOkWLKxQh9ZwO4M2b ZY3k8KU4 UIvnq7an+TzducWg4agXu+TT+ARUDtUXKj81X2oDtUyiyTrU= 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: Gregory Price writes: > On Sat, Apr 12, 2025 at 01:35:56AM +0100, Matthew Wilcox wrote: >> On Fri, Apr 11, 2025 at 08:09:55PM -0400, Gregory Price wrote: >> > On Sat, Apr 12, 2025 at 12:49:18AM +0100, Matthew Wilcox wrote: >> > > On Fri, Apr 11, 2025 at 06:11:05PM -0400, Gregory Price wrote: >> > > > Unmapped page cache pages can be demoted to low-tier memory, but >> > > >> > > No. Page cache should never be demoted to low-tier memory. >> > > NACK this patchset. Hi Matthew, Could you please give some context around why shouldn't page cache be considered as a demotion target if demotion is enabled? Shouldn't demoting page cache pages to a lower tier (when we have enough space in lower tier) can be a better alternative then discarding these pages and later doing I/Os to read them back again? >> > >> > This wasn't a statement of approval page cache being on lower tiers, >> > it's a statement of fact. Enabling demotion causes this issue. >> >> Then that's the bug that needs to be fixed. Not adding 200+ lines >> of code to recover from a situation that should never happen. /me goes and checks when the demotion feature was added... Ok, so I believe this was added here [1] "[PATCH -V10 4/9] mm/migrate: demote pages during reclaim". [1]: https://lore.kernel.org/all/20210715055145.195411-5-ying.huang@intel.com/T/#u I think systems with persistent memory acting as DRAM nodes, could choose to demote page cache pages too, to lower tier instead of simply discarding them and later doing I/O to read them back from disk. e.g. when one has a smaller size DRAM as faster tier and larger size PMEM as slower tier. During memory pressure on faster tier, demoting page cache pages to slower tier can be helpful to avoid doing I/O later to read them back in, isn't it? > > Well, I have a use case that make valuable use of putting the page cache > on a farther node rather than pushing it out to disk. But this > discussion aside, I think we could simply make this a separate mode of > demotion_enabled > > /* Only demote anonymous memory */ > echo 2 > /sys/kernel/mm/numa/demotion_enabled > If we are going down this road... then should we consider what other choices users may need for their usecases? e.g. 0: Demotion disabled 1: Demotion enabled for both anon and file pages Till here the support is already present. 2: Demotion enabled only for anon pages 3: Demotion enabled only for file pages Should this be further classified for dirty v/s clean page cache pages too? > Assuming we can recognize anon from just struct folio I am not 100% sure of this, so others should correct. Should this simply be, folio_is_file_lru() to differentiate page cache pages? Although this still might give us anon pages which have the PG_swapbacked dropped as a result of MADV_FREE. Note sure if that need any special care though? -ritesh