On Wed, 16 Sep 2020 09:11:18 -0700 Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > On Tue, Sep 15, 2020 at 11:03 AM SeongJae Park <sjpark@xxxxxxxxxx> wrote: > > > > From: SeongJae Park <sjpark@xxxxxxxxx> > > > > 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@xxxxxxxxxx/ Thanks, SeongJae Park
