On Fri, 17 Jul 2020 19:47:50 -0700 Shakeel Butt <shakeelb@xxxxxxxxxx> wrote:
> On Mon, Jul 13, 2020 at 1:43 AM SeongJae Park <sjpark@xxxxxxxxxx> wrote:
> >
> > From: SeongJae Park <sjpark@xxxxxxxxx>
> >
> > DAMON is a data access monitoring framework subsystem for the Linux
> > kernel. The core mechanisms of DAMON make it
> >
> > - accurate (the monitoring output is useful enough for DRAM level
> > memory management; It might not appropriate for CPU Cache levels,
> > though),
> > - light-weight (the monitoring overhead is low enough to be applied
> > online), and
> > - scalable (the upper-bound of the overhead is in constant range
> > regardless of the size of target workloads).
> >
> > Using this framework, therefore, the kernel's memory management
> > mechanisms can make advanced decisions. Experimental memory management
> > optimization works that incurring high data accesses monitoring overhead
> > could implemented again. In user space, meanwhile, users who have some
> > special workloads can write personalized applications for better
> > understanding and optimizations of their workloads and systems.
> >
> > This commit is implementing only the stub for the module load/unload,
> > basic data structures, and simple manipulation functions of the
> > structures to keep the size of commit small. The core mechanisms of
> > DAMON will be implemented one by one by following commits.
> >
> > Signed-off-by: SeongJae Park <sjpark@xxxxxxxxx>
> > Reviewed-by: Leonard Foerster <foersleo@xxxxxxxxx>
> > Reviewed-by: Varad Gautam <vrd@xxxxxxxxx>
> > ---
> > include/linux/damon.h | 63 ++++++++++++++
> > mm/Kconfig | 12 +++
> > mm/Makefile | 1 +
> > mm/damon.c | 188 ++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 264 insertions(+)
> > create mode 100644 include/linux/damon.h
> > create mode 100644 mm/damon.c
> >
> > diff --git a/include/linux/damon.h b/include/linux/damon.h
> > new file mode 100644
> > index 000000000000..c8f8c1c41a45
> > --- /dev/null
> > +++ b/include/linux/damon.h
> > @@ -0,0 +1,63 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * DAMON api
> > + *
> > + * Copyright 2019-2020 Amazon.com, Inc. or its affiliates.
> > + *
> > + * Author: SeongJae Park <sjpark@xxxxxxxxx>
> > + */
> > +
[...]
> > +
> > +/**
> > + * struct damon_task - Represents a monitoring target task.
> > + * @pid: Process id of the task.
> > + * @regions_list: Head of the monitoring target regions of this task.
> > + * @list: List head for siblings.
> > + *
> > + * If the monitoring target address space is task independent (e.g., physical
> > + * memory address space monitoring), @pid should be '-1'.
> > + */
> > +struct damon_task {
> > + int pid;
>
> Storing and accessing pid like this is racy. Why not save the "struct
> pid" after getting the reference? I am still going over the usage,
> maybe storing mm_struct would be an even better choice.
>
> > + struct list_head regions_list;
> > + struct list_head list;
> > +};
> > +
[...]
> > +
> > +#define damon_get_task_struct(t) \
> > + (get_pid_task(find_vpid(t->pid), PIDTYPE_PID))
>
> You need at least rcu lock around find_vpid(). Also you need to be
> careful about the context. If you accept my previous suggestion then
> you just need to do this in the process context which is registering
> the pid (no need to worry about the pid namespace).
>
> I am wondering if there should be an interface to register processes
> with DAMON using pidfd instead of integer pid.
Good points! I will use pidfd for this purpose, instead.
BTW, 'struct damon_task' was introduced while DAMON supports only virtual
address spaces and recently extended to support physical memory address
monitoring case by defining an exceptional pid (-1) for such case. I think it
doesn't smoothly fit with the design.
Therefore, I would like to change it with more general named struct, e.g.,
struct damon_target {
void *id;
struct list_head regions_list;
struct list_head list;
};
The 'id' field will be able to store or point pid_t, struct mm_struct, struct
pid, or anything relevant, depending on the target address space.
Only one part of the address space independent logics of DAMON, namely
'kdamon_need_stop()', uses '->pid' of the 'struct damon_task'. It will be
introduced by the next patch ("mm/damon: Implement region based sampling").
Therefore, the conversion will be easy. For the part, I could add another
callback, e.g.,
struct damon_ctx {
[...]
bool (*is_target_valid)(struct damon_target *t);
};
And let the address space specific primitives to implement this.
Then, damon_get_task_struct() and damon_get_mm() will be introduced by the
sixth patch ("mm/damon: Implement callbacks for the virtual memory address
spaces") as a part of the virtual address space specific primitives
implementation.
I gonna make the change in the next spin. If you have some opinions on this,
please let me know.
Thanks,
SeongJae Park
