Date:   Sat, 18 Jul 2020 15:31:06 +0200
From:   SeongJae Park <sjpark@...zon.com>
To:     Shakeel Butt <shakeelb@...gle.com>
CC:     SeongJae Park <sjpark@...zon.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        SeongJae Park <sjpark@...zon.de>,
        <Jonathan.Cameron@...wei.com>,
        Andrea Arcangeli <aarcange@...hat.com>, <acme@...nel.org>,
        <alexander.shishkin@...ux.intel.com>, <amit@...nel.org>,
        <benh@...nel.crashing.org>, <brendan.d.gregg@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Qian Cai <cai@....pw>,
        Colin Ian King <colin.king@...onical.com>,
        Jonathan Corbet <corbet@....net>,
        "David Hildenbrand" <david@...hat.com>, <dwmw@...zon.com>,
        <foersleo@...zon.de>, Ian Rogers <irogers@...gle.com>,
        <jolsa@...hat.com>, "Kirill A. Shutemov" <kirill@...temov.name>,
        <mark.rutland@....com>, Mel Gorman <mgorman@...e.de>,
        Minchan Kim <minchan@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, <namhyung@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Rik van Riel <riel@...riel.com>,
        David Rientjes <rientjes@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>, <rppt@...nel.org>,
        <sblbir@...zon.com>, <shuah@...nel.org>, <sj38.park@...il.com>,
        <snu@...zon.de>, Vlastimil Babka <vbabka@...e.cz>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Huang Ying <ying.huang@...el.com>, <linux-damon@...zon.com>,
        Linux MM <linux-mm@...ck.org>, <linux-doc@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON)

On Fri, 17 Jul 2020 19:47:50 -0700 Shakeel Butt <shakeelb@...gle.com> wrote:

> On Mon, Jul 13, 2020 at 1:43 AM SeongJae Park <sjpark@...zon.com> wrote:
> >
> > From: SeongJae Park <sjpark@...zon.de>
> >
> > 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@...zon.de>
> > Reviewed-by: Leonard Foerster <foersleo@...zon.de>
> > Reviewed-by: Varad Gautam <vrd@...zon.de>
> > ---
> >  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@...zon.de>
> > + */
> > +
[...]
> > +
> > +/**
> > + * 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

Powered by blists - more mailing lists