Re: Re: Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON)

From: SeongJae Park <sj38.park@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: sjpark@amazon.com, akpm@linux-foundation.org,
	SeongJae Park <sjpark@amazon.de>,
	sj38.park@gmail.com, acme@kernel.org, amit@kernel.org,
	brendan.d.gregg@gmail.com, corbet@lwn.net, dwmw@amazon.com,
	mgorman@suse.de, rostedt@goodmis.org, kirill@shutemov.name,
	brendanhiggins@google.com, colin.king@canonical.com,
	minchan@kernel.org, vdavydov.dev@gmail.com,
	vdavydov@parallels.com, linux-mm@kvack.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>
Subject: Re: Re: Re: Re: [PATCH v2 0/9] Introduce Data Access MONitor (DAMON)
Date: Wed, 29 Jan 2020 20:06:45 +0100	[thread overview]
Message-ID: <20200129190645.2137-1-sj38.park@gmail.com> (raw)
In-Reply-To: <20200129180709.GS14879@hirez.programming.kicks-ass.net> (raw)

On Wed, 29 Jan 2020 19:07:09 +0100 Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Jan 29, 2020 at 03:37:58PM +0100, sjpark@amazon.com wrote:
> > On Wed, 29 Jan 2020 13:56:15 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Tue, Jan 28, 2020 at 01:00:33PM +0100, sjpark@amazon.com wrote:
> > > 
> > > > I worried whether it could be a bother to send the mail to everyone in the
> > > > section, but seems it was an unnecessary worry.  Adding those to recipients.
> > > > You can get the original thread of this patchset from
> > > > https://lore.kernel.org/linux-mm/20200128085742.14566-1-sjpark@amazon.com/
> > > 
> > > I read first patch (the document) and still have no friggin clue.
> > 
> > Do you mean the document has insufficient description only?  If so, could you
> > please point me me which information do you want to be added?
> 
> There was a lot of words; but I'm still not sure what it actually does.

Sorry for my bad writing skill.  Will restructure and wordsmith it for next
spin.

> 
> I've read some of the code that followed; is it simply sampling the
> page-table access bit? It did some really weird things though, like that
> whole 3 regions thing.

Because simple Accessed bit sampling cannot preserve the accuracy of the
monitored access patterns, we use the mechanism called 'region based sampling'.
The patch introducing the mechanism would seems weird, mainly because it relies
on another mechanism follows the patch.  I should mentioned about it with the
patch.  I will add the description in next spin so people can understand that.

> 
> Also, you wrote you wanted feedback from perf people; but it doesn't use
> perf, what are you asking?

DAMON aims to be another source of data that perf, other profiling tools, or
even other kernel space code can use.  Therefore I wanted to get some opinions
about whether this data seems useful and how perf developers want the interface
of DAMON to be shaped for co-operation with perf.  Will make this more clear
with next spin's cover letter.

> 
> Perf can do address based sampling of memops, I suspect you can create
> something using that.

If you're saying implementing DAMON in 'perf mem', I think it would conflict
with abovely explained DAMON's goal.

Else, if you're saying it would be the right place to handle the DAMON
generated data, I agree, thank you for pointing me that.  Will keep it in mind
while shaping the interface of DAMON.

Thanks,
SeongJae Park