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 70384C54E71 for ; Fri, 22 Mar 2024 16:32:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E40776B0089; Fri, 22 Mar 2024 12:32:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF0A06B008C; Fri, 22 Mar 2024 12:32:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB9176B0096; Fri, 22 Mar 2024 12:32:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BCD516B0089 for ; Fri, 22 Mar 2024 12:32:34 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9B9AF1C0A57 for ; Fri, 22 Mar 2024 16:32:34 +0000 (UTC) X-FDA: 81925218228.20.5770A8E Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf26.hostedemail.com (Postfix) with ESMTP id 2CF51140016 for ; Fri, 22 Mar 2024 16:32:30 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pmSZoHQN; spf=pass (imf26.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711125151; 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=Nj1yyhBZ4KPozaWgeyXjTkOgRFxTkkta/+IvzvQW+Pk=; b=M1zkygXes24B4R1sLfWEbUMRqEzacU7lPmGILEZTtRXF073VDkiuE59wqrXKIZJqyoh7jX tOv2YH3ybSgD3hzy6TVSoUnNZOyMxPWSMtARvShFlgpmopgn9hfFhAcrBnHwEODGjLbFIL X2BGtTmUM5o3ttEHc1R02SrUseTJhGE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711125151; a=rsa-sha256; cv=none; b=fyCrYcUZBP66OOokh9xqyYTGbssAQNLVoR1B5SYaGCOOCHtCos5sEjOAPqRlP0E+LDINSX koSWBZVNjBl1FohWT1vcEE9iQf0OZgvBIEv59vi4mH9veOZj56XpdBsHX3IzxLm5w4DfaX YI1YsB5sWVlq6WD6I25icOzP9nVmslg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pmSZoHQN; spf=pass (imf26.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id ABDDDCE17FC; Fri, 22 Mar 2024 16:32:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D9E3C433C7; Fri, 22 Mar 2024 16:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711125145; bh=otOiDrXv7vSEtDQG9vjhed+cuW5roGWlH4xO15itNQ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pmSZoHQN6Ch6UZqCQc7YAx+AjlBUk0zUmyDWkFSAOUr+W/ukv/JcU9rjTJiBvBjb7 GXsz3UGT1mXS2A2kC1SCL63D0O7nO0fPEciZIHb5qnrj/l/MV8c8xSV45hVaKRyCHj iXgMDmD2lKxhHoBv3yauwq2+yEpD65CaeqMrAT6L7XmLg58XdtcKR/wru810BF6iN4 5i2JGMs06OEg1a9Jg80csxxv4rEJIg23OPCdKweUEIlDlI0wF15rN83mxbtXgzQ5Ri j+6N14r3eH+37fIr0UrDf3fL8S8WNGVz2uuiO0k7OkQ8Q0tjUSp1N3T9ZVxUrA1/8x iPqVIt4IXrbxQ== From: SeongJae Park To: Honggyu Kim Cc: SeongJae Park , damon@lists.linux.dev, linux-mm@kvack.org, akpm@linux-foundation.org, apopple@nvidia.com, baolin.wang@linux.alibaba.com, dave.jiang@intel.com, hyeongtak.ji@sk.com, kernel_team@skhynix.com, linmiaohe@huawei.com, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, lizhijian@cn.fujitsu.com, mathieu.desnoyers@efficios.com, mhiramat@kernel.org, rakie.kim@sk.com, rostedt@goodmis.org, surenb@google.com, yangx.jy@fujitsu.com, ying.huang@intel.com, ziy@nvidia.com, 42.hyeyoo@gmail.com Subject: Re: [RFC PATCH v2 0/7] DAMON based 2-tier memory management for CXL memory Date: Fri, 22 Mar 2024 09:32:23 -0700 Message-Id: <20240322163223.68414-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240322090227.2253-1-honggyu.kim@sk.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: pqe7bttyites5bkqmjmpk6am53mm8k87 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2CF51140016 X-Rspam-User: X-HE-Tag: 1711125150-66163 X-HE-Meta: U2FsdGVkX1/MxC88T2K3ipFY9WPyx4h6BCPehZaew6Zk5jB1uU+ABmICCWXo3POMec1zbO4pC7lm/csbsgn26lKqC/4WsUw0mhP2BuMtPnQgEoau1wio0my+kjlffCWyn7nQzxcy61D7CKravD54Caytrvt9l4ZKTqvs3LcV9f+lY8VQJgu9KM7gWQ4btYj4/f8kRbuFykmys/cUaEWzh6v/MDmqs+UhsmxGI9AMUhTwi0hq6D0BACjx0rmPyBcPM9aKqtzply0CMA7j6J5CS18BVj3TV6Zwk0OBW9vGjX27RXFAFzi5KRqLIshHB1pDIlFQW2ikPwnbMOP5s+QwUttXKP2ZIdh44Wfg+mu8FAf/GDt0TSXwWTOTEdG+r7GyqrpLndUA2rftxuQR5SRnsDn9ajBp7WItaNOl5UnuomCtuD6s/19lc9h81nd1nO5U2bgQBXgOZylW6SC/VZfBPxVOjV0IgcCzgpoRu3bsffUJk5yxEwySnl+mRl/YQcopIFj6TYPKhmao+DLdO/Xobi6ta0gVJgmfrMsvRBIEdthAGtPLpOUwpKWHH7lHTKZ53ccIGjHVIQ1z3V6S4cL0HS3y7bcLDmJ8zwvqZzifuLqnkccoCarmYSZSiAKpaK/SNlfevRed5hVKJMFIzwf3iGhxYN59cREHRjh+bzAy0pne+LAxSnuJgdZpjH8Cuj6VaMXIDbj87EMOlQeNnxO4B7irR4aV+w053KtG/gUVKDjb/SsVle/Xc8jBaFZG2/iXfYdjyoj25THXmDdTs4Wv6Eb58R0Ifkush4jlxchvIJZ+b21Pi6l2EmvacYc4tz8fTGObNIWLOQclA8B1VvSPDNZJng/w6Tef5x7GDADYKsh4cTDNj9FFg+ipH+IYGUSdVzgOTrMudblDCGzVpOqAKKMCLdq6cJADJ4Ioe89mH3UUnGl7jlAg1FJ9CDRMi6ODGC/5eYBSfogkMbo3FNH 4Y+OcfOA 2qNS5EPSxvHpxG+BrjPMGY7lCpPCVTWyHR6x5r0GCzWS2GlrEOwn1ZSTYzFdpNLmJoKr/QcWJFnLbG6P1GGNufL53OePygDxjLMlisj+5qyA0/VWi3LLxE3yi2ot0+I2847NPt09wv2IUI1/hFQm/HJjGFAn9GkgEd20thQgOHOaks26GPAvUaXeVXLnyy3PlQPYeAvU8XRsA1xqnZkTQSqvqVUGGKM9Oj/iG3jXQtJwKcdCublnYmvP2lGAbUs93rCOgLuN2rUUUXI3EmOlUepD1FF0dzzs11sal/jloLf0fNQETcisYQEVHE9JDK3pedZ7DGNEi6QmrTjD2nBdgriJ+O8UN2MqEyVKMCT4uyX51bkSwT3aWOaY6mQ== 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 Fri, 22 Mar 2024 18:02:23 +0900 Honggyu Kim wrote: > Hi SeongJae, > > On Tue, 27 Feb 2024 15:51:20 -0800 SeongJae Park wrote: > > On Mon, 26 Feb 2024 23:05:46 +0900 Honggyu Kim wrote: > > > > > There was an RFC IDEA "DAMOS-based Tiered-Memory Management" previously > > > posted at [1]. > > > > > > It says there is no implementation of the demote/promote DAMOS action > > > are made. This RFC is about its implementation for physical address > > > space. > > > > > > [...] > > Thank you for running the tests again with the new version of the patches and > > sharing the results! > > It's a bit late answer, but the result was from the previous evaluation. > I ran it again with RFC v2, but didn't see much difference so just > pasted the same result here. No problem, thank you for clarifying :) [...] > > > Honggyu Kim (3): > > > mm/damon: refactor DAMOS_PAGEOUT with migration_mode > > > mm: make alloc_demote_folio externally invokable for migration > > > mm/damon: introduce DAMOS_DEMOTE action for demotion > > > > > > Hyeongtak Ji (4): > > > mm/memory-tiers: add next_promotion_node to find promotion target > > > mm/damon: introduce DAMOS_PROMOTE action for promotion > > > mm/damon/sysfs-schemes: add target_nid on sysfs-schemes > > > mm/damon/sysfs-schemes: apply target_nid for promote and demote > > > actions > > > > Honggyu joined DAMON Beer/Coffee/Tea Chat[1] yesterday, and we discussed about > > this patchset in high level. Sharing the summary here for open discussion. As > > also discussed on the first version of this patchset[2], we want to make single > > action for general page migration with minimum changes, but would like to keep > > page level access re-check. We also agreed the previously proposed DAMOS > > filter-based approach could make sense for the purpose. > > Thanks very much for the summary. I have been trying to merge promote > and demote actions into a single migrate action, but I found an issue > regarding damon_pa_scheme_score. It currently calls damon_cold_score() > for demote action and damon_hot_score() for promote action, but what > should we call when we use a single migrate action? Good point! This is what I didn't think about when suggesting that. Thank you for letting me know this gap! I think there could be two approach, off the top of my head. The first one would be extending the interface so that the user can select the score function. This would let flexible usage, but I'm bit concerned if this could make things unnecessarily complex, and would really useful in many general use case. The second approach would be letting DAMON infer the intention. In this case, I think we could know the intention is the demotion if the scheme has a youg pages exclusion filter. Then, we could use the cold_score(). And vice versa. To cover a case that there is no filter at all, I think we could have one assumption. My humble intuition says the new action (migrate) may be used more for promotion use case. So, in damon_pa_scheme_score(), if the action of the given scheme is the new one (say, MIGRATE), the function will further check if the scheme has a filter for excluding young pages. If so, the function will use cold_score(). Otherwise, the function will use hot_score(). So I'd more prefer the second approach. I think it would be not too late to consider the first approach after waiting for it turns out more actions have such ambiguity and need more general interface for explicitly set the score function. Thanks, SJ [...]