[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c273f5a8797a6c00c8ce004b0979961873d4fcf0.camel@amazon.com>
Date: Fri, 21 May 2021 08:55:18 +0000
From: "Shah, Amit" <aams@...zon.de>
To: "sj38.park@...il.com" <sj38.park@...il.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC: "david@...hat.com" <david@...hat.com>,
"rientjes@...gle.com" <rientjes@...gle.com>,
"acme@...nel.org" <acme@...nel.org>,
"snu@...zon.de" <snu@...zon.de>,
"peterz@...radead.org" <peterz@...radead.org>,
"minchan@...nel.org" <minchan@...nel.org>,
"vdavydov.dev@...il.com" <vdavydov.dev@...il.com>,
"linux-damon@...zon.com" <linux-damon@...zon.com>,
"zgf574564920@...il.com" <zgf574564920@...il.com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"fan.du@...el.com" <fan.du@...el.com>,
"Park, Seongjae" <sjpark@...zon.de>,
"amit@...nel.org" <amit@...nel.org>,
"gthelen@...gle.com" <gthelen@...gle.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"Foerster, Leonard" <foersleo@...zon.de>,
"guoju.fgj@...baba-inc.com" <guoju.fgj@...baba-inc.com>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"shakeelb@...gle.com" <shakeelb@...gle.com>,
"Woodhouse, David" <dwmw@...zon.co.uk>,
"greg@...ah.com" <greg@...ah.com>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"rppt@...nel.org" <rppt@...nel.org>,
"mgorman@...e.de" <mgorman@...e.de>,
"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"brendanhiggins@...gle.com" <brendanhiggins@...gle.com>,
"corbet@....net" <corbet@....net>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"elver@...gle.com" <elver@...gle.com>,
"riel@...riel.com" <riel@...riel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v29 00/13] Introduce Data Access MONitor (DAMON)
Hey Andrew,
On Thu, 2021-05-20 at 15:34 -0700, Andrew Morton wrote:
> 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.
There are a few kernel developers at Amazon watching over this effort,
and nudging it along. But more importantly, we're working with fleet
owners operating large fleets to guide this effort.
That makes the overall effort a 2-phase one: profiling first (which is
what this patchset does), and then improving other things that use this
profiling information for better system efficiencies.
All that's primarily for use-cases internally right now. Once the base
set of patches is upstream, we're going to work on all the various use-
cases we've identified so far where this is going to be beneficial.
Current internal uses are mainly around profiling. One example is
mentioned by SeongJae in the cover letter's "Real-world User Story"
section, where tuning page reclamation algorithms based on this
profiling information is going to result in better efficiencies, and
energy and cost reductions.
Another interesting usecase that's developing is identifying free pages
for reclamation and compaction based on this work. That's going to
help live migration and memory overcommit scenarios for KVM guests. SJ
is preparing to send out those patches to the lists as well.
Thanks!
Amit
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
Powered by blists - more mailing lists