public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Jann Horn <jannh@google.com>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
	Pedro Falcato <pfalcato@suse.de>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	damon@lists.linux.dev, kernel-team@meta.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC v2 0/7] mm/damon: extend for page faults reporting based access monitoring
Date: Sat,  6 Dec 2025 20:52:56 -0800	[thread overview]
Message-ID: <20251207045257.47035-1-sj@kernel.org> (raw)
In-Reply-To: <20250727201813.53858-1-sj@kernel.org>

On Sun, 27 Jul 2025 13:18:06 -0700 SeongJae Park <sj@kernel.org> wrote:

> TL; DR: Extend DAMON interface between core and operation sets for
> operation set driven report-based monitoring such as per-CPU and
> write-only access monitoring.  Further introduce an example physical
> address space monitoring operation set that uses page faults as the
> source of the information.
[...]
> Core Layer Changes for Reporting-based Monitoring
> -------------------------------------------------
> 
> Optimize such possible duplicated efforts, by updating DAMON core layer
> to support real time access reporting.  The updated interface allows
> operations set implementations to report (or, push) their information to
> the core layer, on their preferred schedule.  DAMON core layer will
> handle the reports by managing meta data and updating the final
> monitoring results (DAMON regions) accordingly.
> 
> Also add another operations set callback to determine if a given access
> report is eligible to be used for a given operations set.  For example,
> if the operations set implementation is for monitoring only specific CPU
> or writes, the operations set could ask the core layer to ignore
> reported accesses that were made by other CPUs, or were made for reads.
> 
> paddr_fault: Page Faults-based Physical Address Space Access Monitoring
> -----------------------------------------------------------------------
> 
> Using the core layer changes, implement a new DAMON operation set,
> namely paddr_fault.  It is the same as the page table Accessed bits
> based physical address space monitoring, but uses page faults as the
> source of the access information.
> 
> Specifically, it installs PAGE_NONE protection to access sampling pages
> on damon_operations->prepare_access_checks() callback.  Then, it
> captures the following access to the page in the page fault handling
> context, and directly reports the findings to DAMON, using
> damon_report_access().

I was going in this direction because obviously the protection installing is
obviously what operation set layer should do.  But, damon_report_access()
handling is on the core layer.  For followup extension for
per-CPUs/threads/read/write monitoring, we need to filtr in/out the page fault
information, but that's not only for page fault but general access check
sampling results.  And therefore it makes more sense to be done in core layer.

Also this approach is unnecessarily increasing the number of operation set.  It
is also restricting such advanced monitoring to specific operation set.

So I changed my mind to add a control data structure on the core layer.  It
will let API callers specify what access check primitives (or, sources) should
be used, and what access information should be filtered in/out.


Thanks,
SJ

[...]


      parent reply	other threads:[~2025-12-07  4:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-27 20:18 [RFC v2 0/7] mm/damon: extend for page faults reporting based access monitoring SeongJae Park
2025-07-27 20:18 ` [RFC v2 1/7] mm/damon/core: introduce damon_report_access() SeongJae Park
2025-07-27 20:18 ` [RFC v2 2/7] mm/damon/core: add eligible_report() ops callback SeongJae Park
2025-07-27 20:18 ` [RFC v2 3/7] mm/damon/vaddr: implement eligible_report() SeongJae Park
2025-07-27 20:18 ` [RFC v2 4/7] mm/damon/core: read received access reports SeongJae Park
2025-07-27 20:18 ` [RFC v2 5/7] mm/memory: implement MM_CP_DAMON SeongJae Park
2025-07-28  5:19   ` Lorenzo Stoakes
2025-07-29  3:06     ` SeongJae Park
2025-07-29  9:40       ` Lorenzo Stoakes
2025-07-30  4:21         ` SeongJae Park
2025-07-31 12:18           ` Lorenzo Stoakes
2025-07-27 20:18 ` [RFC v2 6/7] mm/damon: implement paddr_fault operations set SeongJae Park
2025-07-27 20:18 ` [RFC v2 7/7] mm/damon/sysfs: support paddr_fault SeongJae Park
2025-08-04  2:47 ` [RFC v2 0/7] mm/damon: extend for page faults reporting based access monitoring Andrew Paniakin
2025-08-04 16:57   ` SeongJae Park
2025-12-07  4:52 ` SeongJae Park [this message]

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=20251207045257.47035-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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