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 A47B1C369B5 for ; Tue, 15 Apr 2025 00:45:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A73DB2800B1; Mon, 14 Apr 2025 20:45:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A22982800A7; Mon, 14 Apr 2025 20:45:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EA712800B1; Mon, 14 Apr 2025 20:45:50 -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 714592800A7 for ; Mon, 14 Apr 2025 20:45:50 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 660CB160872 for ; Tue, 15 Apr 2025 00:45:51 +0000 (UTC) X-FDA: 83334435702.17.F73FBB3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf14.hostedemail.com (Postfix) with ESMTP id C320710000C for ; Tue, 15 Apr 2025 00:45:49 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="umPjU/w9"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744677949; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bHKmVO138cphBpSC1um6kl0Uj4egw4V9SRjg/PIhkLg=; b=J8JYBZqd8dxYtKZjtaxhD+0h4yQzqWCkFxLqbJ7qlOtvwP/w545v4n958C4En13QXBbdGH CJOI1M7K5y9fZ3g3DCHGAZtxwXOrB/1tqT3f6Mg2b0jts3r5ZEBD3xj+EP8pgfk45uJRk5 kQ5Q7xxE3FF8kByFAo0lHbpSNCnv6Gg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="umPjU/w9"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744677949; a=rsa-sha256; cv=none; b=vAK3s75HSdUC56WYefHTQWIXa0w0kpi15AXcWMPjytooqWCFCM7fYLrtUm9R66GtRvP2OX HOa7qbxGw6EkRyQAlS1OSQxVtMNIXlqOdjqCNyguNfyL5L3WS4EqZpTBj+2Ka2SDJDMKlB thh+UMb+gMLzPIJnUsiMuFhVdYLIKW0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CD540A40DDB; Tue, 15 Apr 2025 00:40:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1ACEC4CEE2; Tue, 15 Apr 2025 00:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744677948; bh=WKSZ9P4DIHoVsccjrV42uB5sUQZKjrJNYr1+QUfW9JE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=umPjU/w9Rvom1YvLze6XEeUX4etDIO0Icz+q3/HNKovi7UmoXQ3JeAok2TpPTKypS SAxP9Rkt5FEQ0o90Qv8SR0Jh7QvR9D8gjkwZqXlQ8ffGX+7Ouv609HMl04G5O9TXyI WqMT3NKf2e/8DR/5GH+WJlMZ23cJHW1QPLJIR9G/YRFlbZ3Mz84DaGMXe4GG0rQA5w pamcouc5TzFrzn2b6/6dYMRyRQ4QtNHwbdeswnReCTNeq/7YipNerchtoVIy8R9O9N 51T0bh26DEMeryrtTK+0HJ0NVZjOyyPCD71+tQSmBgoGv1CreYnoJFW9QGGTyUcbC5 NOzFq1540Rc4w== From: SeongJae Park To: Gregory Price Cc: SeongJae Park , 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. Date: Mon, 14 Apr 2025 17:45:46 -0700 Message-Id: <20250415004546.121566-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250411221111.493193-1-gourry@gourry.net> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: C320710000C X-Stat-Signature: bfpkbta3yuef3wrnfusaiegc1tp9fid7 X-Rspam-User: X-HE-Tag: 1744677949-87919 X-HE-Meta: U2FsdGVkX19PgbtOuRrIEYtJ7Pm6Y7OeWA8ugB1ZKmkK8GO1iS3Ssf81EBWhHhSJHJaOE8fnLq/1YZTsFbvctWxnMDkreAf+4qQd45C+XnKbbJkY/VhSf8OjmPE3+6bbbfO51rFMPab4GeBckGhmwQZBi+2jffWwmEPNYWTpPiD/I5E5xfTlVqSc+5HzbuTJDdkEPWRFwAYTcgn3N/VpYCvjh/8Z8XFTsAJPm/TIjwIfhrOh6HRdI5TRXKQ2t9BoQMkpKROEichMQRF7QAnkTtZ664DkbAcFP5l7Cssc3IqlxG8DUf8vpE6XHztSsIfAo7DKgRWvC8j4Il1PrnelJxOXc+1KOCrH+2B4pxy52RezL1NGzy6/bSuEccWyAxlVFbRnAoCSZxHLYOYTJsPJJ8ChBY3GW+J6YeqBNfJ+SwrcUiJHSHVADpCBTRadAFV8lgm/ztJQAU9p1AskEfJu6KQon49Fcan0YiEFgISy6b68MgYoW4fOoYEHm5/GqVhNel37++mdi9Ox2Dfv3nWJEFd+yIezgMHWBRaVcqBPUPowFdRMA+vUDffRP7MeSEmUOFWR/i2Zptbfnrqs33UZRFjtJp/3S+f7j2BiAn/TjVORCrrJJa9aSz4KBaF2qrpaCvf31ortpzDe/iuBtIAYvmvU1yrPTxSXrU44qrqhHN7bLWYbkwcDUSSY5ewfzpwuKf3WHTyhCsjf0fYkxiCcdp0GFsXWtz6kgc+/soCcM1RUjUkw/FYviGmWbWtNxzm7nJ2f67hVOe1+7vB5fgMhwOtRkOYfxigazfKMbUdepTyyhGspbMsfqOttQI4IV1R3FdWMM/b829mm8To8uLp5Ct4bkABI7YjyxJVbE2HXGq0Qw5mqOv9YJAVHItdmioM6EQU16LbBSnIoBbBmAehnr3j+CXgIeayyTQRDJLvATngQVPTY3qD3Hi285uTh8rXWQR92OAU1T1lfUEMH5fY KnBSsRjW PUnN1hVwk1XjeiBCY1Bqg3JLFuJmn+teTGO8pLLn/9yqEAgfvtnlmvk1DwsECSdMuF20M3tEJ1JiE7M1b4rgSsAnPAUc68ceiSVwK3BqFfr7MMPyUawPkwIFcE4eVDe/4zc/SEfHyDppPlSqoYicsuSxHSTQ9IV92Efo7qb575TWhwTJcj/XmbFGazugJtBwrvfJwB4b1Vtz/mEDeVolyLWVM0p+6OT7ZrM5M5bpK8JPOvoKnvLHGLRum3ht/MRT/pr6TocfHbpiYtTmQ12GyNK8bZXwdq63JMYLUFM8nJQ1114VRokzvV/jGYX2VhU+IGyV6PFqO2fE79mjUe2Aoi60m0pFLJZMDg4gB 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: Hi Gregory, Thank you for continuing and sharing this nice work. Adding some comments based on my humble and DAMON-biased perspective below. On Fri, 11 Apr 2025 18:11:05 -0400 Gregory Price wrote: > Unmapped page cache pages can be demoted to low-tier memory, but > they can presently only be promoted in two conditions: > 1) The page is fully swapped out and re-faulted > 2) The page becomes mapped (and exposed to NUMA hint faults) Yet another way is running DAMOS with DAMOS_MIGRATE_HOT action and unmapped pages DAMOS filter. Or, without unmapped pages DAMOS filter, if you want to promote both mapped and unmapped pages. It is easy to tell, but I anticiapte it will show many limitations on your use case. I anyway only very recently shared[1] my version of experimental prototype and its evaluation results. I also understand this patch series is the simple and well working solution for your use case, and I have no special blocker for this work. Nevertheless, I was just thinking it would be nice if your anticipated or expected limitations and opportunities of other approaches including DAMON-based one can be put here together. [...] > > Development History and Notes > ======================================= > During development, we explored the following proposals: This is very informative and helpful for getting the context. Thank you for sharing. [...] > 4) Adding a separate kthread - suggested by many DAMON-based approach might also be categorized here since DAMON does access monitoring and monitoring results-based system operations (migration in this context) in a separate thread. > > This is - to an extent - a more general version of the LRU proposal. > We still have to track the folios - which likely requires the > addition of a page flag. In case of DAMON-based approach, this is not technically true, since it uses its own abstraction called DAMON region. Of course, DAMON region abstraction is not a panacea. There were concerns around the accuracy of the region abstraction. We found unoptimum DAMON intervals tuning could be one of the source of the poor accuracy and recently made an automation[2] of the tuning. I remeber you previously mentioned it might make sense to utilize DAMON as a way to save such additional information. It has been one of the motivations for my recent suggestion of a new DAMON API[3], namely damon_report_access(). It will allow any kernel code reports their access finding to DAMON with controlled overhead. The aimed usage is to make page faults handler, folio_mark_accessed(), and AMD IBS sample handers like code path passes the information to DAMON via the API function. > Additionally, this method would actually > contend pretty heavily with LRU behavior - i.e. we'd want to > throttle addition to the promotion candidate list in some scenarios. DAMON-based approach could use DAMOS quota feature for this kind of purpose. > > > 5) Doing it in task work > > This seemed to be the most realistic after considering the above. > > We observe the following: > - FMA is an ideal hook for this and isolation is safe here My one concern is that users can ask DAMON to call folio_mark_accessed() for non unmapped page cache folios, via DAMOS_LRU_PRIO. Promoting the folio could be understood as a sort of LRU-prioritizing, so I'm not really concerned about DAMON's behavioral change that this patch series could introduce. Rather than that, I'm concerned if vmstat change of this patch series could be confused by such DAMON users. > - the new promotion_candidate function is an ideal hook for new > filter logic (throttling, fairness, etc). Agreed. DAMON's target filtering and aim-based aggressiveness self-tuning features could be such logic. I suggested[3] damos_add_folio() as a potential future DAMON API for such use cases. With this patch series, nevertheless, only folio_mark_accessed() called folios could get such opportunity. Do you have future plans to integrate faults-based promotion logic with this function, and extend for other access information source? [1] https://lore.kernel.org/20250320053937.57734-1-sj@kernel.org [2] https://lkml.kernel.org/r/20250303221726.484227-1-sj@kernel.org [3] https://lwn.net/Articles/1016525/ Thanks, SJ [...]