Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   SeongJae Park <sj38.park@gmail.com>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     SeongJae Park <sj38.park@gmail.com>,
        Shakeel Butt <shakeelb@google.com>,
        SeongJae Park <sjpark@amazon.de>, Jonathan.Cameron@huawei.com,
        amit@kernel.org, Jonathan Corbet <corbet@lwn.net>,
        David Hildenbrand <david@redhat.com>, dwmw@amazon.com,
        foersleo@amazon.de, Greg Thelen <gthelen@google.com>,
        jgowans@amazon.com, mheyne@amazon.de,
        David Rientjes <rientjes@google.com>, sieberf@amazon.com,
        Vlastimil Babka <vbabka@suse.cz>, linux-damon@amazon.com,
        Linux MM <linux-mm@kvack.org>, linux-doc@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>, Wei Xu <weixugc@google.com>,
        Paul Turner <pjt@google.com>, Yu Zhao <yuzhao@google.com>,
        Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH v34 00/13] Introduce Data Access MONitor (DAMON)
Date:   Fri,  6 Aug 2021 11:48:01 +0000
Message-Id: <20210806114801.6958-1-sjpark@amazon.de>
In-Reply-To: <20210805170344.afbf5f1ceb00eb212082ca7b@linux-foundation.org>
Precedence: bulk

From: SeongJae Park <sjpark@amazon.de>

On Thu, 5 Aug 2021 17:03:44 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 28 Jul 2021 08:36:43 +0000 SeongJae Park <sj38.park@gmail.com> wrote:
> 
> > > DAMON does not expose stable APIs at the moment, so these can
> > > be changed later if needed. I think it is ok to merge DAMON for some
> > > exposure. However I do want to make this clear that the solution space
> > > is not complete. The solution of system level monitoring is still
> > > needed which can be a future extension to DAMON or more generalized
> > > Multigen LRU.
> > 
> > Agreed.  We have lots more works to do.  Some of those are already posted as
> > RFC patchsets[1,2,3,4].  I promise I will happily do the works.  But, how dare
> > could only I get all the fun?  I'd like to do that together with others in this
> > great community.  One major purpose of this patchset is thus providing a
> > flexible framework for such collaboration.  The virtual address space
> > monitoring, which this patchset provides in addition to the framework, is also
> > for real-world usages, though.
> > 
> > Now all the patches have at least one 'Reviewed-by:' or 'Acked-by:' tags.  We
> > didn't find serious problems since v26[5], which was posted about four months
> > ago. so I'm thinking this patchset has passed the minimum qualification.  If
> > you think there are more things to be done before this patchset is merged in
> > the -mm tree or mainline, please let me know.  If not, Andrew, I'd like you to
> > consider merging this patchset into '-mm' tree.
> 
> Shall take a look.  With some trepidation.
> 
> 1-2 years from now someone will pop up with a massive patchset
> implementing some monitoring scheme and we'll say "why didn't you use
> DAMON" and they'll say "it's unsuitable for <reasons>".

Agreed.  And I personally believe merging this in will help avoiding such
situation, because the someone will be able to easily find the developer who is
responsible to convince the person.  I will happily and definitely do my best
for that.

> 
> I would like to see more thought/design go into how DAMON could be
> modified to address Shakeel's other three requirements.  At least to
> the point where we can confidently say "yes, we will be able to do
> this".  Are you able to drive this discussion along please?

Sure.  I will describe my plan for convincing Shakeel's usages in detail as a
reply to this mail.


Thanks,
SeongJae Park