Re: [RFC PATCH 2/2] mm/damon/debugfs: Support multiple contexts

[SeongJae Park <sjpark@amazon.com>]

On Wed, 16 Sep 2020 09:11:18 -0700 Shakeel Butt <shakeelb@google.com> wrote:

> On Tue, Sep 15, 2020 at 11:03 AM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > From: SeongJae Park <sjpark@amazon.de>
> >
> > DAMON allows the programming interface users to run monitoring with
> > multiple contexts.  This could be useful in some cases.  For example, if
> > someone want to do highly accurate monitoring and lots of CPUs are
> > available, splitting the monitoring target regions into multiple small
> > regions and allocating context (monitoring thread) to each small region
> > could be helpful.  Or, someone could need to monitor different types of
> > address spaces simultaneously.
> >
> > However, it's impossible from the user space because the DAMON debugfs
> > interface supports only single context.  This commit makes it available
> > by implementing 'nr_contexts' debugfs file.
> >
> > Users can pass the number (N) of contexts they want to use to the file.
> 
> Why not just mkdir which will create a new context?

Because I referenced the naming rule of zram and because I just wanted to make
this as simple as possible.  I find no special functional difference between
current way and you suggested way.

That said, I also think you suggested way is much more flexible.  I will try to
make this in that way.

> 
> > Then, N folders having name of 'ctx<1-(N-1)>' are created in the DAMON
> > debugfs dir.  Each of the directory is associated with the contexts and
> > contains the the files for context setting (attrs, init_regions, record,
> > schemes, and target_ids).
> 
> Also instead of naming the kthread with context number why not give
> the kthread pids through attrs (or new interface) and the admin can
> move those kthreads to the cgroup they want to charge against?

Again, I just wanted to make this as simple as possible, and I also referenced
blkback thread naming.  And I find no special functional difference here,
either.

And yes, I think you suggested way is much more flexible and easy to be used.
I will make this in that way.

---

Just a note (not for only Shakeel, but anyone who interested in DAMON).  The
DAMON debugfs interface is not highly coupled with DAMON.  Rather than that, it
is implemented as an application using DAMON as a framework via the DAMON's
kernel space interface.  This means that anyone who want different user space
interface can implement their own on top of the framework.  I will try to make
the changes as soon as possible, but if you cannot wait until then, you could
implement your own.

Similarly, DAMON lacks many functionality such as support of special address
spaces.  I already have a TODO list.  And I will implement those one by one.
So, please give me the requests.  However, I believe the kernel space interface
is already almost complete.  Thus, almost every such future features could be
implemented on top of current DAMON interface.  Therefore, if you cannot wait
until I finish the work, you can implement your own on DAMON's kernel space
interface.

Of course, if you send the patches for your own implementations, that will make
not only I, but the community happier.

And this is the reason why the patchset containing only the framework part and
minimal applications / addons is titled as official 'PATCH', while the
patchsets for the future features are titled 'RFC'.  So, I am asking you to
consider giving more attention to the framework part (the first 4 patches of
the patchset[1]), as all future features will depend on it.

[1] https://lore.kernel.org/linux-mm/20200817105137.19296-1-sjpark@amazon.com/


Thanks,
SeongJae Park