[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvZod6Q1kMaEN+PTEJ39D4hYfjtLcPQhKND8m2p7KYui5pKTA@mail.gmail.com>
Date: Thu, 20 May 2021 19:53:02 -0700
From: Shakeel Butt <shakeelb@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: SeongJae Park <sj38.park@...il.com>,
SeongJae Park <sjpark@...zon.de>, Jonathan.Cameron@...wei.com,
acme@...nel.org, alexander.shishkin@...ux.intel.com,
amit@...nel.org, benh@...nel.crashing.org,
Brendan Higgins <brendanhiggins@...gle.com>,
Jonathan Corbet <corbet@....net>,
David Hildenbrand <david@...hat.com>, dwmw@...zon.com,
Marco Elver <elver@...gle.com>, "Du, Fan" <fan.du@...el.com>,
foersleo@...zon.de, greg@...ah.com,
Greg Thelen <gthelen@...gle.com>, guoju.fgj@...baba-inc.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>,
Rik van Riel <riel@...riel.com>,
David Rientjes <rientjes@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Mike Rapoport <rppt@...nel.org>, Shuah Khan <shuah@...nel.org>,
snu@...zon.de, Vlastimil Babka <vbabka@...e.cz>,
Vladimir Davydov <vdavydov.dev@...il.com>,
zgf574564920@...il.com, linux-damon@...zon.com,
Linux MM <linux-mm@...ck.org>, linux-doc@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v29 00/13] Introduce Data Access MONitor (DAMON)
On Thu, May 20, 2021 at 3:34 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Thu, 20 May 2021 07:56:16 +0000 SeongJae Park <sj38.park@...il.com> wrote:
>
> > Changes from Previous Version (v28)
>
> Thanks for persisting with this.
>
> I'd be interested in people's overall take on this work, please.
> Mainly a high-level "should we merge this" view. Detailed review of
> implementation and interface details can follow on in the usual fashion.
I am planning to go over the whole series but first let me give my
high-level view on the patch series.
In my personal opinion, this patch series is in the state where we can
merge this or at least add to the mm tree for further exposure.
I have pushed SeongJae to keep the functionality to bare minimum in
the first version and focus more on making the design extensible, so
as more use-cases arise, the core can be extended accordingly.
I am actually more interested in the followup of this work which would
be extended to monitor cgroups for use-cases like hugepages, balancing
hot/cold memory in memory tiers and hints for malloc implementations.
Powered by blists - more mailing lists