Message-Id: <20250415004546.121566-1-sj@kernel.org>
Date: Mon, 14 Apr 2025 17:45:46 -0700
From: SeongJae Park <sj@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: SeongJae Park <sj@...nel.org>,
	linux-mm@...ck.org,
	cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	kernel-team@...a.com,
	akpm@...ux-foundation.org,
	mingo@...hat.com,
	peterz@...radead.org,
	juri.lelli@...hat.com,
	vincent.guittot@...aro.org,
	hannes@...xchg.org,
	mhocko@...nel.org,
	roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev,
	donettom@...ux.ibm.com,
	Huang Ying <ying.huang@...ux.alibaba.com>,
	Keith Busch <kbusch@...a.com>,
	Feng Tang <feng.tang@...el.com>,
	Neha Gholkar <nehagholkar@...a.com>
Subject: Re: [RFC PATCH v4 0/6] Promotion of Unmapped Page Cache Folios.

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 <gourry@...rry.net> 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

[...]

Powered by blists - more mailing lists