Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: krJH/h/cdwPHjEodCrYJ8eWlIbRiijS485C97GeaCDI19ic6DTngNqATvDNMcCECngWFWtTnD4
 xMwZJ2pDh7JQ==
From:   SeongJae Park <sjpark@amazon.com>
To:     Shakeel Butt <shakeelb@google.com>
CC:     SeongJae Park <sjpark@amazon.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        SeongJae Park <sjpark@amazon.de>,
        <Jonathan.Cameron@huawei.com>,
        Andrea Arcangeli <aarcange@redhat.com>, <acme@kernel.org>,
        <alexander.shishkin@linux.intel.com>, <amit@kernel.org>,
        <benh@kernel.crashing.org>, <brendan.d.gregg@gmail.com>,
        Brendan Higgins <brendanhiggins@google.com>,
        Qian Cai <cai@lca.pw>,
        Colin Ian King <colin.king@canonical.com>,
        Jonathan Corbet <corbet@lwn.net>,
        "David Hildenbrand" <david@redhat.com>, <dwmw@amazon.com>,
        <foersleo@amazon.de>, Ian Rogers <irogers@google.com>,
        <jolsa@redhat.com>, "Kirill A. Shutemov" <kirill@shutemov.name>,
        <mark.rutland@arm.com>, Mel Gorman <mgorman@suse.de>,
        Minchan Kim <minchan@kernel.org>,
        Ingo Molnar <mingo@redhat.com>, <namhyung@kernel.org>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        Rik van Riel <riel@surriel.com>,
        David Rientjes <rientjes@google.com>,
        Steven Rostedt <rostedt@goodmis.org>, <rppt@kernel.org>,
        <sblbir@amazon.com>, <shuah@kernel.org>, <sj38.park@gmail.com>,
        <snu@amazon.de>, Vlastimil Babka <vbabka@suse.cz>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Yang Shi <yang.shi@linux.alibaba.com>,
        Huang Ying <ying.huang@intel.com>, <linux-damon@amazon.com>,
        Linux MM <linux-mm@kvack.org>, <linux-doc@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH v18 02/14] mm: Introduce Data Access MONitor (DAMON)
Date:   Sat, 18 Jul 2020 15:31:06 +0200
Message-ID: <20200718133106.4787-1-sjpark@amazon.com>
In-Reply-To: <CALvZod7MZaE52408O6eGNpGGW77xFTyr56YK0F7qjNH1HX98MQ@mail.gmail.com> (raw)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

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