Re: [PATCH v34 00/13] Introduce Data Access MONitor (DAMON)

[SeongJae Park]

From: SeongJae Park <sjpark@xxxxxxxxx>

Hello Andrew,

On Mon,  2 Aug 2021 08:24:24 +0000 SeongJae Park <sj38.park@xxxxxxxxx> wrote:

> From: SeongJae Park <sjpark@xxxxxxxxx>
> 
> Hello Andrew,
> 
> On Wed, 28 Jul 2021 08:36:43 +0000 SeongJae Park <sj38.park@xxxxxxxxx> wrote:
> 
> [...]
> > 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.
> 
> I'm wondering if you had a chance to consider that.  If you had the chance but
> this patchset didn't convince you, could you please let me know your concerns
> so that I can make some progress?

Because nearly three weeks passed since this patchset is posted, I considered
rebasing it on the latest -mm tree and posting it as v35.  But, apparently it
makes no much sense because we found nothing to fix or improve.  And, this
version can still cleanly be applied on top of the latest -mm tree.  So,
instead of merely increasing the version number, I'd like to describe why I
believe this need to be merged into the -mm tree and eventually the mainline.

1. Merging this patchset will not bother other developers

Most changes in this patchset are for DAMON-dedicated new source files.  There
is a change[1] for existing files, which makes PG_Idle independent of Idle Page
Tracking, but it is only small.  Therefore, merging this patchset will not
increase the complexity of the other parts or introduce a regression.

2. Merging this patchset will not bother other users

DAMON utilizes a mechanism that designed to minimize and limit the monitoring
overhead.  That said, DAMON can be opt out in the compile time for users who
don't want it.  Even though it is compiled, it does nothing at all unless a
user explicitly asks it to do some works.  Therefore, merging this patchset
will not silently introduce any additional overhead to users.

3. This patchset is deployed to real users

We are currently using DAMON patchset for profiling production workloads, as
described in 'Real-world User Story' section of the cover letter.  It is also
deployed to real users other than us via Amazon Linux[2,3].  A few companies
and several researchers outside Amazon have publicly and/or privately shown
their interests in DAMON.

4. The downstream-only maintenance overhead is significant

Following development works based on DAMON[4,5,6] are also ongoing.  Because
all the works are currently in downstream only, the maintenance overhead is not
small for us.  Once DAMON is upstreamed, the overhead will significantly be
reduced.

5. This patchset is reviewed and apparently is stabilized

Since the first version of DAMON patchset is posted (2020-01-20), it has
evolved a lot.  All patches of this patchset got at least one 'Reviewed-by:' or
'Acked-by:' tag by v31[7], which have posted about seven weeks ago
(2021-06-21).  After that, we found and fixed only minor issues.  We also got a
few more 'Acked-by:' tags.  Since v34, which has posted about three weeks ago,
we found no more issues.  We are also continuously running extensive
DAMON-dedicated tests.  The tests include unit tests, self tests, functional
tests, performance tests, and static code analysis.  Some of those are also
publicly available[8].

[1] https://lore.kernel.org/linux-mm/20210716081449.22187-5-sj38.park@xxxxxxxxx/
[2] https://github.com/amazonlinux/linux/tree/amazon-5.4.y/master/mm/damon
[3] https://github.com/amazonlinux/linux/tree/amazon-5.10.y/master/mm/damon
[4] https://lore.kernel.org/linux-mm/20201216084404.23183-1-sjpark@xxxxxxxxxx/
[5] https://lore.kernel.org/linux-mm/20201216094221.11898-1-sjpark@xxxxxxxxxx/
[6] https://lore.kernel.org/linux-mm/20210720131309.22073-1-sj38.park@xxxxxxxxx/
[7] https://lore.kernel.org/linux-mm/20210621083108.17589-1-sj38.park@xxxxxxxxx/
[8] https://github.com/awslabs/damon-tests


If you think above explanation makes sense, please consider merging this into
the -mm tree.  Else, if this doesn't convince you, please let me know your
concerns or what I'm missing, so that I can make some progress.


Thanks,
SeongJae Park

[...]