Linux-Doc Archive on lore.kernel.org
 help / color / Atom feed
From: SeongJae Park <sjpark@amazon.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: SeongJae Park <sjpark@amazon.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	SeongJae Park <sjpark@amazon.de>, <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>,
	<foersleo@amazon.de>, 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>, <linux-damon@amazon.com>,
	Linux MM <linux-mm@kvack.org>, <linux-doc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Re: Re: [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces
Date: Fri, 17 Jul 2020 18:24:03 +0200
Message-ID: <20200717162403.26170-1-sjpark@amazon.com> (raw)
In-Reply-To: <CALvZod6+kTri_Z2xeo=mVi8tvQfa6L7NSXqh_kfSxvPCd6uDVQ@mail.gmail.com> (raw)

On Fri, 17 Jul 2020 08:17:09 -0700 Shakeel Butt <shakeelb@google.com> wrote:

> On Thu, Jul 16, 2020 at 11:54 PM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > On Thu, 16 Jul 2020 17:46:54 -0700 Shakeel Butt <shakeelb@google.com> wrote:
> >
> > > On Mon, Jul 13, 2020 at 1:44 AM SeongJae Park <sjpark@amazon.com> wrote:
> > > >
> > > > From: SeongJae Park <sjpark@amazon.de>
> > > >
> > > > This commit introduces a reference implementation of the address space
> > > > specific low level primitives for the virtual address space, so that
> > > > users of DAMON can easily monitor the data accesses on virtual address
> > > > spaces of specific processes by simply configuring the implementation to
> > > > be used by DAMON.
> > > >
> > > > The low level primitives for the fundamental access monitoring are
> > > > defined in two parts:
> > > > 1. Identification of the monitoring target address range for the address
> > > > space.
> > > > 2. Access check of specific address range in the target space.
> > > >
> > > > The reference implementation for the virtual address space provided by
> > > > this commit is designed as below.
> > > >
> > > > PTE Accessed-bit Based Access Check
> > > > -----------------------------------
> > > >
> > > > The implementation uses PTE Accessed-bit for basic access checks.  That
> > > > is, it clears the bit for next sampling target page and checks whether
> > > > it set again after one sampling period.  To avoid disturbing other
> > > > Accessed bit users such as the reclamation logic, the implementation
> > > > adjusts the ``PG_Idle`` and ``PG_Young`` appropriately, as same to the
> > > > 'Idle Page Tracking'.
> > > >
> > > > VMA-based Target Address Range Construction
> > > > -------------------------------------------
> > > >
> > > > Only small parts in the super-huge virtual address space of the
> > > > processes are mapped to physical memory and accessed.  Thus, tracking
> > > > the unmapped address regions is just wasteful.  However, because DAMON
> > > > can deal with some level of noise using the adaptive regions adjustment
> > > > mechanism, tracking every mapping is not strictly required but could
> > > > even incur a high overhead in some cases.  That said, too huge unmapped
> > > > areas inside the monitoring target should be removed to not take the
> > > > time for the adaptive mechanism.
> > > >
> > > > For the reason, this implementation converts the complex mappings to
> > > > three distinct regions that cover every mapped area of the address
> > > > space.  Also, the two gaps between the three regions are the two biggest
> > > > unmapped areas in the given address space.  The two biggest unmapped
> > > > areas would be the gap between the heap and the uppermost mmap()-ed
> > > > region, and the gap between the lowermost mmap()-ed region and the stack
> > > > in most of the cases.  Because these gaps are exceptionally huge in
> > > > usual address spacees, excluding these will be sufficient to make a
> > > > reasonable trade-off.  Below shows this in detail::
> > > >
> > > >     <heap>
> > > >     <BIG UNMAPPED REGION 1>
> > > >     <uppermost mmap()-ed region>
> > > >     (small mmap()-ed regions and munmap()-ed regions)
> > > >     <lowermost mmap()-ed region>
> > > >     <BIG UNMAPPED REGION 2>
> > > >     <stack>
> > > >
> > > > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > > > Reviewed-by: Leonard Foerster <foersleo@amazon.de>
> > > [snip]
> > > > +
> > > > +static void damon_mkold(struct mm_struct *mm, unsigned long addr)
> > > > +{
> > > > +       pte_t *pte = NULL;
> > > > +       pmd_t *pmd = NULL;
> > > > +       spinlock_t *ptl;
> > > > +
> > > > +       if (follow_pte_pmd(mm, addr, NULL, &pte, &pmd, &ptl))
> > > > +               return;
> > > > +
> > > > +       if (pte) {
> > > > +               if (pte_young(*pte)) {
> > >
> > > Any reason for skipping mmu_notifier_clear_young()? Why exclude VMs as
> > > DAMON's target applications?
> >
> > Obviously my mistake, thank you for pointing this!  I will add the function
> > call in the next spin.
> >
> 
> Similarly mmu_notifier_test_young() for the damon_young().

Yes, indeed.  Thanks for pointing this, either :)

> BTW I think we can combine ctx->prepare_access_checks() and
> ctx->check_accesses() into one i.e. get the young state for the previous
> cycle and mkold for the next cycle in a single step.

Yes, we could.  But, I'm unsure what is the advantage of doing that.  First of
all, if the combined implementation is required, peopld could simply implement
the two logics in the combined way in one of the callbacks and leave the other
one blank.  Also, I'm worrying if combining those could make the code a little
bit hard to read.  IMHO, I think separating those makes the 'kdamond_fn()' code
little bit easier to read.  Actually, I started from the combined approach but
separated the two logics since v7 after Jonathan's comment[1].


[1] https://lore.kernel.org/linux-mm/20200310085721.00000a0f@Huawei.com/


> 
> I am wondering if there is any advantage to having "Page Idle
> Tracking" beside DAMON. I think we can make them mutually exclusive.
> Once we have established that I think DAMON can steal the two page
> flag bits from it and can make use of them. What do you think?

Again, yes, I think we could.  But I don't see clear advantage of it for now.


Thanks,
SeongJae Park

  reply index

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13  8:41 [PATCH v18 00/14] Introduce Data Access MONitor (DAMON) SeongJae Park
2020-07-13  8:41 ` [PATCH v18 01/14] mm/page_ext: Export lookup_page_ext() to GPL modules SeongJae Park
2020-07-13 12:08   ` Mike Rapoport
2020-07-13 12:21     ` SeongJae Park
2020-07-13 17:19       ` Mike Rapoport
2020-07-13 17:38         ` SeongJae Park
2020-07-17  9:59           ` SeongJae Park
2020-07-13  8:41 ` [PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON) SeongJae Park
2020-07-18  2:47   ` Shakeel Butt
2020-07-18 13:31     ` SeongJae Park
2020-07-29 15:31       ` Shakeel Butt
2020-07-29 17:29         ` SeongJae Park
2020-07-13  8:41 ` [PATCH v18 03/14] mm/damon: Implement region based sampling SeongJae Park
2020-07-13  8:41 ` [PATCH v18 04/14] mm/damon: Adaptively adjust regions SeongJae Park
2020-07-13  8:41 ` [PATCH v18 05/14] mm/damon: Track dynamic monitoring target regions update SeongJae Park
2020-07-13  8:41 ` [PATCH v18 06/14] mm/damon: Implement callbacks for the virtual memory address spaces SeongJae Park
2020-07-17  0:46   ` Shakeel Butt
2020-07-17  6:53     ` SeongJae Park
2020-07-17 15:17       ` Shakeel Butt
2020-07-17 16:24         ` SeongJae Park [this message]
2020-07-18  2:23           ` Shakeel Butt
2020-07-18  2:51             ` SeongJae Park
2020-07-27  7:34   ` Greg Thelen
2020-07-27  9:02     ` SeongJae Park
2020-07-28 17:42       ` Shakeel Butt
2020-07-29  6:20         ` SeongJae Park
2020-07-13  8:41 ` [PATCH v18 07/14] mm/damon: Implement access pattern recording SeongJae Park
2020-07-13  8:41 ` [PATCH v18 08/14] mm/damon: Add a tracepoint SeongJae Park
2020-07-13  8:41 ` [PATCH v18 09/14] mm/damon: Implement a debugfs interface SeongJae Park
2020-07-22 10:36   ` SeongJae Park
2020-07-13  8:41 ` [PATCH v18 10/14] tools: Introduce a minimal user-space tool for DAMON SeongJae Park
2020-07-13  8:41 ` [PATCH v18 11/14] Documentation: Add documents " SeongJae Park
2020-07-27  7:19   ` Greg Thelen
2020-07-27  7:38     ` SeongJae Park
2020-07-13  8:41 ` [PATCH v18 12/14] mm/damon: Add kunit tests SeongJae Park
2020-07-13  8:41 ` [PATCH v18 13/14] mm/damon: Add user space selftests SeongJae Park
2020-07-13  8:41 ` [PATCH v18 14/14] MAINTAINERS: Update for DAMON 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=20200717162403.26170-1-sjpark@amazon.com \
    --to=sjpark@amazon.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aarcange@redhat.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.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=foersleo@amazon.de \
    --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=sjpark@amazon.de \
    --cc=snu@amazon.de \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    --cc=yang.shi@linux.alibaba.com \
    --cc=ying.huang@intel.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

Linux-Doc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-doc/0 linux-doc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-doc linux-doc/ https://lore.kernel.org/linux-doc \
		linux-doc@vger.kernel.org
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-doc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git