linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: lsf-pc@lists.linux-foundation.org
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: [LSF/MM/BPF TOPIC] DAMON Updates and Plans: Monitoring Parameters Auot-tuning and Memory Tiering
Date: Thu,  2 Jan 2025 14:23:17 -0800	[thread overview]
Message-ID: <20250102222317.48760-1-sj@kernel.org> (raw)

Hi all,


We started sharing and discussing DAMON's current status and future plans from
LSF/MM/BPF 2023.  Thanks to the constructive feedbacks from the discussions, I
believe DAMON is continuing the evolution in right or at least not
controversial directions.  To continue getting the benefit and avoid it becomes
an unexpected "demon" in early stage, I'd like to share and discuss followup
updates and new plans for DAMON once again on LSF/MM/BPF 2025.

Major topics and currently expected materials to share on the session include
below.  Of course, some changes could happen.

First, followups on work items that we discussed on last LSF/MM/BPF.

DAMOS auto-tuning based tiered memory manamgent.  No many progress has made so
far.  But I recently gained an access to a tiered memory system, and setting up
test environment.  Hopefully I will be able to share early RFC implementation
and evaluation results by the session.

Access/Contiguity-aware Memory Auto-scalging.  No progress has made so far,
too.  I'm pivoting this into reliable huge contig memory occupation
mechanism, though, since it is smaller scope that we can make faster.  It can
also be used for not only memory hotplugging based auto-scaling but also
contiguous memory allocation.  Hopefully early evaluation of a part of the
work, probably access-aware partial compaction, will be shared by the session.

Please refer to last year LSF/MM/BPF slides[1] for details of the above two
projects.

And new projects that currently in their early stages.

Page level properties-based access monitoring.  We are extending DAMOS filters
that works in page level properties to further be useful for monitoring
purpose.  RFC patch series for the essential part[1] is already available, and
user-space tool support[2] is made.  By the session, hopefully the patch series
will be merged in mm tree, and I will be able to share followup plans for
making it more lightweight and useful.

Extending DAMON for memory bandwidth monitoring.  We aim to extend DAMON to
support not only access pattern snapshot generation, but more general access
pattern information, like memory bandwidth usage.  I expect only rough idea
will be shared on the session, to make early alignemnt of the future shape, or
abortion.

Please let me know if you have interest in status of other projects that I
shared on last LSF/MM/BPF session or somewhere else.  Depending on that, the
topics and time portions can be changed.

Note that I proposed[3] yet another LSF/MM/BPF topic for DAMON.  If both are
accepted, please schedule this one before the other one.  I believe this
session can make the other session deduplicated and faster.

[1] https://github.com/damonitor/talks/blob/master/2024/lsfmmbpf/damon_lsfmmbpf_2024.pdf
[2] https://damonitor.github.io/posts/damon_sz_filter_passed/
[3] https://lore.kernel.org/20250101222039.74565-1-sj@kernel.org


Thanks,
SJ


             reply	other threads:[~2025-01-02 22:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02 22:23 SeongJae Park [this message]
2025-01-21 10:01 ` Jonathan Cameron
2025-01-21 18:31   ` SeongJae Park
2025-03-25 20:59 ` 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=20250102222317.48760-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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