linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sjpark@amazon.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: SeongJae Park <sjpark@amazon.com>, <Jonathan.Cameron@huawei.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>, <acme@kernel.org>,
	<alexander.shishkin@linux.intel.com>, <amit@kernel.org>,
	<benh@kernel.crashing.org>, <brendan.d.gregg@gmail.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	Qian Cai <cai@lca.pw>, Colin Ian King <colin.king@canonical.com>,
	Jonathan Corbet <corbet@lwn.net>,
	"David Hildenbrand" <david@redhat.com>, <dwmw@amazon.com>,
	"Du, Fan" <fan.du@intel.com>, <foersleo@amazon.de>,
	Greg Thelen <gthelen@google.com>, Ian Rogers <irogers@google.com>,
	<jolsa@redhat.com>, "Kirill A. Shutemov" <kirill@shutemov.name>,
	<mark.rutland@arm.com>, Mel Gorman <mgorman@suse.de>,
	Minchan Kim <minchan@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	<namhyung@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Rik van Riel <riel@surriel.com>,
	David Rientjes <rientjes@google.com>,
	Steven Rostedt <rostedt@goodmis.org>, <rppt@kernel.org>,
	<sblbir@amazon.com>, <shuah@kernel.org>, <sj38.park@gmail.com>,
	<snu@amazon.de>, Vlastimil Babka <vbabka@suse.cz>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Yang Shi <yang.shi@linux.alibaba.com>,
	Huang Ying <ying.huang@intel.com>, <zgf574564920@gmail.com>,
	<linux-damon@amazon.com>, Linux MM <linux-mm@kvack.org>,
	<linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v7 06/10] mm/damon: Implement callbacks for physical memory monitoring
Date: Thu, 20 Aug 2020 16:28:05 +0200	[thread overview]
Message-ID: <20200820142805.10234-1-sjpark@amazon.com> (raw)
In-Reply-To: <CALvZod4i5f5RcsHao3DWddoDgHsO+vvGPZaAJUWkURZ2fqH9LA@mail.gmail.com>

On Thu, 20 Aug 2020 06:26:49 -0700 Shakeel Butt <shakeelb@google.com> wrote:

> On Thu, Aug 20, 2020 at 12:17 AM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > On Wed, 19 Aug 2020 17:26:15 -0700 Shakeel Butt <shakeelb@google.com> wrote:
> >
> > > On Tue, Aug 18, 2020 at 12:27 AM SeongJae Park <sjpark@amazon.com> wrote:
> > > >
> > > > From: SeongJae Park <sjpark@amazon.de>
> > > >
> > > > This commit implements the four callbacks (->init_target_regions,
> > > > ->update_target_regions, ->prepare_access_check, and ->check_accesses)
> > > > for the basic access monitoring of the physical memory address space.
> > > > By setting the callback pointers to point those, users can easily
> > > > monitor the accesses to the physical memory.
> > > >
> > > > Internally, it uses the PTE Accessed bit, as similar to that of the
> > > > virtual memory support.  Also, it supports only user memory pages, as
> > > > idle page tracking also does, for the same reason.  If the monitoring
> > > > target physical memory address range contains non-user memory pages,
> > > > access check of the pages will do nothing but simply treat the pages as
> > > > not accessed.
> > > >
> > > > Users who want to use other access check primitives and/or monitor the
> > > > non-user memory regions could implement and use their own callbacks.
> > > >
> > > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > [snip]
> > > > +static void damon_phys_mkold(unsigned long paddr)
> > > > +{
> > > > +       struct page *page = damon_phys_get_page(PHYS_PFN(paddr));
> > > > +       struct rmap_walk_control rwc = {
> > > > +               .rmap_one = damon_page_mkold,
> > > > +               .anon_lock = page_lock_anon_vma_read,
> > > > +       };
> > > > +       bool need_lock;
> > > > +
> > > > +       if (!page)
> > > > +               return;
> > > > +
> > > > +       if (!page_mapped(page) || !page_rmapping(page))
> > > > +               return;
> > >
> > > I don't think you want to skip the unmapped pages. The point of
> > > physical address space monitoring was to include the monitoring of
> > > unmapped pages, so, skipping them invalidates the underlying
> > > motivation.
> >
> > I think my answer to your other mail[1] could be an answer to this.  Let me
> > quote some from it:
> >
> > ```
> > Technically speaking, this patchset introduces an implementation of DAMON's low
> > level primitives for physical address space of LRU-listed pages.  In other
> > words, it is not designed for cgroups case.  Also, please note that this
> > patchset is only RFC, because it aims to only show the future plan of DAMON and
> > get opinions about the concept before being serious.  It will be serious only
> > after the DAMON patchset is merged.  Maybe I didn' made this point clear in the
> > CV, sorry.  I will state this clearly in the next spin.
> > ```
> 
> The unmapped pages are also LRU pages.

Sorry, I missed the detail.  So, the description should be updated to:

    This patchset introduces an implementation of DAMON's low level primitives
    for physical addressspace of _mapped_ LRU pages.

> Let's forget about the cgroups
> support for a moment, the only reason to use DAMON's physical address
> space monitoring is also to track the accesses of unmapped pages
> otherwise virtual address space monitoring already does the monitoring
> for mapped pages.

Well, I didn't intended the use case...  I just wanted to let people see the
data accesses on physical address space without tracking every mappings of the
pages.

Anyway, ok, we could consider supporting unmapped pages, but I'm unsure why and
how much it is necessary.  After all, who could access unmapped pages?  Could
you give me more details on the needs for access monitoring of the unmapped
pages?


Thanks,
SeongJae Park


  reply	other threads:[~2020-08-20 14:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  7:24 [RFC v7 00/10] DAMON: Support Physical Memory Address Space Monitoring SeongJae Park
2020-08-18  7:24 ` [RFC v7 01/10] mm/damon/debugfs: Allow users to set initial monitoring target regions SeongJae Park
2020-08-18  7:24 ` [RFC v7 02/10] tools/damon: Support init target regions specification SeongJae Park
2020-08-18  7:24 ` [RFC v7 03/10] mm/damon-test: Add more unit tests for 'init_regions' SeongJae Park
2020-08-18 19:22   ` Brendan Higgins
2020-08-18  7:24 ` [RFC v7 04/10] selftests/damon/_chk_record: Do not check number of gaps SeongJae Park
2020-08-18  7:24 ` [RFC v7 05/10] Docs/admin-guide/mm/damon: Document 'init_regions' feature SeongJae Park
2020-08-18  7:24 ` [RFC v7 06/10] mm/damon: Implement callbacks for physical memory monitoring SeongJae Park
2020-08-20  0:26   ` Shakeel Butt
2020-08-20  7:16     ` SeongJae Park
2020-08-20 13:26       ` Shakeel Butt
2020-08-20 14:28         ` SeongJae Park [this message]
2020-08-28  8:11   ` Alkaid
2020-08-28  9:53     ` SeongJae Park
2020-08-28 11:39       ` SeongJae Park
2020-08-18  7:24 ` [RFC v7 07/10] mm/damon/debugfs: Support " SeongJae Park
2020-08-18  7:24 ` [RFC v7 08/10] tools/damon/record: " SeongJae Park
2020-08-18  7:25 ` [RFC v7 09/10] tools/damon/record: Support NUMA specific recording SeongJae Park
2020-08-18  7:25 ` [RFC v7 10/10] Docs/DAMON: Document physical memory monitoring support SeongJae Park
2020-08-20  1:21 ` [RFC v7 00/10] DAMON: Support Physical Memory Address Space Monitoring Shakeel Butt
2020-08-20  7:10   ` SeongJae Park
2020-08-20 15:44     ` Shakeel Butt
2020-08-20 17:33       ` 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=20200820142805.10234-1-sjpark@amazon.com \
    --to=sjpark@amazon.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aarcange@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=amit@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=brendan.d.gregg@gmail.com \
    --cc=brendanhiggins@google.com \
    --cc=cai@lca.pw \
    --cc=colin.king@canonical.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=dwmw@amazon.com \
    --cc=fan.du@intel.com \
    --cc=foersleo@amazon.de \
    --cc=gthelen@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=linux-damon@amazon.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=riel@surriel.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=sblbir@amazon.com \
    --cc=shakeelb@google.com \
    --cc=shuah@kernel.org \
    --cc=sj38.park@gmail.com \
    --cc=snu@amazon.de \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    --cc=yang.shi@linux.alibaba.com \
    --cc=ying.huang@intel.com \
    --cc=zgf574564920@gmail.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;
as well as URLs for NNTP newsgroup(s).