linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Yuanchu Xie <yuanchu@google.com>
Cc: SeongJae Park <sj@kernel.org>, Gregory Price <gourry@gourry.net>,
	lsf-pc@lists.linux-foundation.org, damon@lists.linux.dev,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, Raghavendra K T <raghavendra.kt@amd.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Kaiyang Zhao <kaiyang2@cs.cmu.edu>,
	Jiaming Yan <jiamingy@amazon.com>,
	Honggyu Kim <honggyu.kim@sk.com>
Subject: Re: [LSF/MM/BPF TOPIC] DAMON Requirements for Access-aware MM of Future
Date: Wed, 29 Jan 2025 19:47:49 -0800	[thread overview]
Message-ID: <20250130034749.49417-1-sj@kernel.org> (raw)
In-Reply-To: <CAJj2-QF1y1XNRYy9sT5c5=pi20+67Duf9B2Amatnu01HLmw06Q@mail.gmail.com>

Hi Yuanchu,

On Wed, 29 Jan 2025 18:15:08 -0800 Yuanchu Xie <yuanchu@google.com> wrote:

> On Mon, Jan 13, 2025 at 7:06 PM Gregory Price <gourry@gourry.net> wrote:
> > 5) Scarce resources
> >
> >    We need to be careful not to consume excessive amounts of resources
> >    in an attempt to track all these identifying mechanisms.  Even 1 byte
> >    per folio is 256MB on a 1TB machine.  This gets out of hand quick.
> >
> >    With task-work, I was able to add no additional resource consumption,
> >    but deferring to a fully async scenario and needing to track things
> >    like last-accessing CPU, timestamps, and etc.
> >
> >    We'll need to examine this closely if we decide to aggregate either
> >    of these mechanisms.
> My concern with physical address space monitoring is fragmentation. I
> ran some numbers on a few prod machines. Grouping by regions with the
> same memcg and ignoring any unmapped memory to be generous, machines
> with higher utilization can have a region/total pages ratio of ~40%,
> and even those with lower utilization (<50%) can also reach 20%.
> Accurately tracking these regions would require quite the region
> metadata, on the order of GBs.

You're right, if we need page level accuracy access monitoring and want to use
DAMON with its regions based mechanism for that, the memory overhead of
damon_region could be high.  That's mainly because DAMON's regions-based
mechanism has not designed for such usage.  It is more for a best-effort
tradeoff between the overhead and the accuracy.

Regions-based mechanism is not necessarily the only mechanism of future DAMON,
though.  If there are use cases that regions-based best-effort accuracy cannot
be used while exactly the page level accuracy is really required, we can think
about optimizing regions based mechanism or developing new one.

But, IMHO, the page level accurate access pattern is not always essential.  In
many cases, being able to distinguish some amount of regions agains others
based on access pattern is practical enough.  Indeed, DAMON has been used on
real-world products with physical address based moitoring mode for years with
no significant problem.  Also I think physical address space based monitoring
results[1] on a real server workload that I shared recently seems not very bad.

Of course your use case could be different from what I have experienced so far.
I'm curious if and why you really need page level accuracy.

[1] https://lore.kernel.org/20250110185232.54907-3-sj@kernel.org


Thanks,
SJ


  reply	other threads:[~2025-01-30  3:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-01 22:20 SeongJae Park
2025-01-02  4:09 ` Matthew Wilcox
2025-01-02 15:22   ` Gregory Price
2025-01-02 18:00     ` SeongJae Park
2025-01-02 18:04       ` SeongJae Park
2025-01-14  3:06 ` Gregory Price
2025-01-24  2:11   ` SeongJae Park
2025-01-24 17:21     ` Gregory Price
2025-01-25  1:17       ` SeongJae Park
2025-01-30  2:15   ` Yuanchu Xie
2025-01-30  3:47     ` SeongJae Park [this message]
2025-01-31 10:05       ` Jonathan Cameron
2025-01-20 18:46 ` Jonathan Cameron
2025-03-25 21:01 ` SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250130034749.49417-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=damon@lists.linux.dev \
    --cc=gourry@gourry.net \
    --cc=honggyu.kim@sk.com \
    --cc=jiamingy@amazon.com \
    --cc=kaiyang2@cs.cmu.edu \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=raghavendra.kt@amd.com \
    --cc=yuanchu@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox